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ABSTRACT 


LOCOSS  (L_ogic  £f  £omputers  Operating  System  for  the  PDP- 
Seven)  was  developed  to  provide  a  suitable  run-time  environment 
in  which  to  run  applications  programs.  Multiprogramming  capa¬ 
bilities  are  an  essential  part  of  the  system  and  allow  a  flex¬ 
ible  organization.  Provision  is  made  for  alternate  methods  of 
establishing  a  separate  (parallel)  line  of  execution  and  for 
invoking  a  subtask.  EVENTS  provide  a  flexible  means  of  inter¬ 
task  communication.  A  keyboard  Command  Interpreter  provides 
a  number  of  real-time  control  services  and  simple  debugging 
aids.  Input/output  is  buffered,  overlapped,  and  essentially 
device-independent,  allowing  users  to  write  programs  with  re¬ 
ferences  to  generalized  "sources"  and  "sinks."  I/O  devices 
supported  are:  teletype,  paper  tape  reader  and  punch,  201A 
dataphone,  IBM  1800  (the  disk  file  system  and  running  programs), 
and  the  337  display  as  a  character  sink.  Additional  subroutines 
are  available  for  such  user  needs  as  reading  and  writing  octal 
or  decimal  numbers,  loading  a  program  from  the  IBM  1800  disk, and 
setting  an  interval  timer. 
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1.  INTRODUCTION 


This  is  the  first  of  three  related  reports  describing  work 
performed  by  members  of  the  Logic  of  Computers  Group,  a  research 
unit  of  the  Department  of  Computer  and  Communication  Sciences 
at  The  University  of  Michigan. 

The  Logic  of  Computers  Group  computer  facility  consists  of 
two,  small,  general-purpose  computers  and  related  peripheral 
equipment.  It  is  intended  to  provide  a  vehicle  for  heuristic 
investigation  of  problems  involving  large-scale  simulations  of 
generalized  adaptive  systems,  including  a  large  class  of  biolog¬ 
ically  oriented  models. 

This  report  documents  those  portions  of  the  system  software 
that  are  largely  or  completely  finished,  and  that  are  not  likely 
to  undergo  further  substantial  development.  It  is  intended  to 

1.  serve  as  a  progress  and  research  report  describing  the 
capabilities  of  the  current  software, 

2.  serve  as  a  user's  manual,  and 

3.  provide  enough  system  information  to  allow  later  users 
to  modify  or  maintain  the  system 

While  these  are  system  types  of  programs,  their  development 
has  been  necessary  to  allow  for  further  work.  The  LOCOSS  system 
for  the  PDP-7  and  the  1800  file  system  are  basic  and  flexible 
tools.  Descriptions  of  several  other  systems  components  are  in¬ 
cluded  for  completeness.  The  particular  hardware  configuration 
is  summarized  at  the  end  of  this  section. 
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In  general,  the  TSX  system  provided  by  IBM  is  the  basic 
software  nucleus  for  the  1800.  LOCOSS  is  the  basic  software 
nucleus  on  the  PDP-7. 

LOCOSS  is  the  Logic  of  Computers  Operating  System  for  the 
PDP-Seven.  It  was  developed  to  provide  a  suitable  run-time 
environment  in  which  to  run  application  programs.  It  provides 
buffered,  overlapped,  and  essentially  device- independent  input/ 
output.  A  keyboard  Command  Interpreter  provides  a  number  of 
real-time  control  services  and  simple  debugging  aids.  Multi¬ 
programming  capabilities  are  an  essential  part  of  the  system 
organization  and  allow  flexible  organization  of  application 
programs . 

LOCOSS,  in  our  estimation,  provides  unusually  flexible 
capabilities  and  services  on  a  machine  of  this  size,  and  requires 
less  than  2K  (decimal)  of  core. 

The  availability  of  bulk  storage  on  the  1800  disk  via  the 
"minor"  1800-PDP-7  interface  (in  use  since  April  1968)  made  it 
feasible  to  provide  system  programs  and,  perhaps  more  important¬ 
ly,  user  source  files,  "on-line." 

To  implement  this,  a  disk  file  system  was  developed  for  the 
1800.  This  system  provides  vari ab 1 e -  1 ength ,  s erial -by- character 
data  files  to  both  1800  and  PDP-7  users.  Both  symbolic  and 
binary  data  are  kept  on-line  in  this  manner.  A  keyboard  utility 
routine  on  the  1800  provides  simple  means  to  load,  dump,  list, 
or  copy  from  or  to  all  1800  1/0  devices  and  the  disk  files. 

Even  the  approximately  tripled  listing  rate  possible  with  the 
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1050  printer  (15  characters  per  second,  hardware  tabs)  has  been 
very  useful.  The  pace  of  program  development  accelerated  great¬ 
ly  as  it  became  possible  to  be  more  and  more  disk-oriented.  It 
was  necessary  to  provide  a  new  text  editor  because  modification 
of  the  available  one  proved  impossible.  In  addition  to  taking 
advantage  of  the  device-independent  I/O  of  L0C0SS,  the  editor 
provides  a  couple  of  string  search  and  replacement  commands  that 
are  quite  useful. 

The  PDP-7  Assembler  was  adapted  to  accept  disk  file  input, 
although  it  still  punches  object  code  on  tape.  DDT  was  made 
available  on-line,  and  may  be  loaded  and  called  from  LOCOSS. 

A  very  powerful  macro  language,  ML-I,  was  adapted  to  the  disk 
I/O  and  made  a  part  of  the  system.  Thus  program  creation,  edit¬ 
ing,  assembly,  debugging,  and  execution  all  take  place  on-line 
under  control  of  LOCOSS  with  a  minimum  of  superfluous  hard  copy 
generation . 

While  the  current  interface  is  sufficiently  fast  for  these 
human-oriented  tasks,  it  will  not  suffice  for  the  kind  of  inter¬ 
active  processing  desired  for  the  prob 1 em- oriented  system. 
Therefore,  the  authois  designed  a  high-speed,  general-purpose 
interface  (described  in  a  separate  report*).  It  offers  flexi¬ 
bility  and  control  substantially  beyond  current  interfacing 
practice  as  we  know  it.  The  general  ideas  employed  in  it  should 

*  Brender,  R.F.,  and  Foy,  J.L.  Jr.,  Flexible  High-Speed 

Interface  between  I BM  1800  and  DEC  PDP-7  Computers ,  Technical 
Report  12,  Concomp  Project,  University  of  Michigan,  Ann  Arbor, 
October  1968. 
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be  very  useful  in  other  multiple  computer  systems  (as  opposed 
to  multiple  CPU  systems  with  common  memory).  Implementation 
of  thi  interface  should  be  completed  by  the  end  of  1968,  and 
more  complete  reports  on  it  will  be  issued  later. 


PDP-7  System  Summary 


CPU 

8K  of  1 .  7  5|J  s  e  c  core 
18  bits/word 
hardware  interrupt 

Teleprinter  (33KSR) 

10  char  per  second 

Paper  Tape  Reader 
8-channel 

300  char  per  second 

Paper  Tape  Punch 
8- channel 

63  char  per  second 

Dataphone  (201A) 

synchronous 

2000  bits  per  second 

connected  to  switched  network 

CRT  Display  (Modified  338) 

A  display  consisting  of  a  DEC  338,  less  the  PDP-8  portion 
of  the  338,  is  interfaces  to  the  PDP-7.  This  is  locally 
known  as  a  337  and  is  the  prototype  for  the  DEC  339.  The 
display  operates  asynchronously  from  instruction  files  in 
the  PDP-7  memory.  It  provides  point,  increment,  short 
vector,  vector,  and  character  plotting  modes  and  is  capable 
of  branches  and  subroutining  as  well  as  conditional  branches 
depending  on  the  state  of  user-controlled  switches. 


-5- 


1800  System  Summary 


CPU  (1801C2) 

16K  of  2ysec  core 

16  bits/word  +  parity  and  storage  protection 
priority  interrupt  system  (12  levels) 

3  index  registers 

1-  and  2-word  instruction  formats 

4  data  channels 

Keyboard- Printer  (1816) 

15  chars/sec 

Card  Read-Punch  (1442) 

Read  300  cards  per  minute 
Punch  60  cards  per  minute 

Disk  (2310A1 ) 

1  drive 
movable  head 

interchangeable  cartridges  (2315) 

512,000  words  per  cartridge 
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2.  LOCOSS  USER'S  MANUAL 


2 . 1  Introduction 

LOCOSS  resides  in  the  lower  part  of  core,  locations 
0-4377  octal;  all  user  programs  are  loaded  above  it  and  up  to 
the  loader  area,  locations  17600-17777  octal.  LOCOSS  is  organ¬ 
ized  into  four  main  areas:  the  multiprogramming  monitor,  the 
Command  Language  Interpreter,  general  service,  and  input/output 
routines.  Functions  within  these  areas  are  generally  available 
as  subroutine  calls  through  a  system  transfer  vector  and  commu¬ 
nication  area  in  low  core. 

2.1.1  Summary  of  System  Components 

Multiprogramming.  The  multiprogramming  in  LOCOSS  is  less 
of  an  attempt  to  provide  a  facility  for  running  independent 
production  jobs  than  it  is  an  organization  of  system  resources. 
On-line  systems  tend  to  be  rather  cumbersome  if  they  must  as¬ 
sume  all  responsibility  for  the  user  interaction  while  trying 
to  execute  complicated  programs  which  are  sometimes  hopelessly 
interdependent.  By  providing  independent  lines  of  execution  and 
some  means  of  allocating  resources,  multiprogramming  makes 
complex  tasks  easier,  at  least  conceptually.  Less  complicated 
programs  may  be  run  as  a  single  task  under  the  monitor,  and 
the  user  does  not  have  to  worry  about  the  basic  system  organi¬ 
zation. 

The  standard  method  of  starting  a  user  program,  once  it 
has  been  loaded,  is  to  INSERT  it  into  the  task  queue  as  an 
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independent  line  of  execution  from  the  Command  Language  Inter¬ 
preter.  From  then  on  the  program  may  choose  its  mode  of  opera¬ 
tion. 

Command  Language  Interpreter.  The  Command  Language  Inter¬ 
preter  (CLI)  is  a  part  of  the  teletype  keyboard  package  that 
accepts  commands  in  real  time  from  the  user  and  acts  upon  them. 
Since  the  CLI  is  essentially  an  i nt errupt- time  package  it  can¬ 
not  be  "locked  out"  by  task  time  routines,  unless  these  routines 
fail  to  observe  the  standard  system  convention  of  operating  with 
"interrupts  on"  (ION).  From  the  CLI,  the  user  can  direct  such 
operations  as:  starting  up  new  lines  of  execution  (tasks), 
dumping  or  changing  core  locations,  controlling  the  state  of 
the  IBM  1 800- interrupt  service  routines  for  the  PDP-7,  loading 
new  programs  from  the  disk,  and  assigning  specific  devices  to  the 
generalized  I/O  ports. 

General  Service  Routines.  The  user-oriented  routines  pro¬ 
vide  services  that  are  required  in  practically  all  programs  as, 
for  example,  reading  and  writing  octal  or  decimal  numbers,  out- 
putting  text  lists,  setting  an  interval  timer,  etc. 

Input  and  Output.  Input/output  is  interrupt-driven  and  is 
buffered  and  overlapped  as  much  as  possible.  Users  are  ex¬ 
pected  to  operate  their  programs  with  interrupts  on  and  to  per¬ 
form  all  I/O  (except  special  display  handling)  through  the 
system  routines,  although  there  is  provision  for  reassigning 
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the  management  for  a  particular  device  if  the  user  so  desires. 
Character  buffering  for  all  devices  is  performed  by  routines 
which  are  available  to  the  user  for  specialized  application. 

The  "devices"  currently  supported  (through  L0C0SS-3)  are: 
teletype  (keyboard  input,  teleprinter  output),  paper  tape  reader 
and  punch,  201A  dataphone  (simulated  full  duplex),  IBM  1800 
logical  disk  file  (read  and  write  independently),  IBM  1800 
copy  port  (and  through  it  the  card  reade r /punch ,  console  keyboard 
and  printer,  disk  files,  and  running  programs  in  the  1800),  and 
the  337  as  a  sink  for  characters  to  be  displayed  on  the  screen. 
Among  these,  the  support  routines  for  the  teletype,  paper  tape 
routines,  and  IBM  1800  disk  and  copy  port  routines  are  resident 
in  L0C0SS.  The  dataphone  and  display  routines  are  available  as 
independent  packages  and  may  be  loaded  into  core,  in  predesig¬ 
nated  areas,  by  calling  system  subroutine  LOAD,  or  by  loading 
the  appropriate  binary  tape. 

Device  Independence.  Most  1/0  routines  have  identical 
calling  sequences  so  that  a  large  measure  of  device  independence 
is  possible.  Users  may  write  their  programs  with  1/0  references 
to  generalized  "sources"  and  "sinks,"  and  then  at  run-time  assign 
specific  devices  to  these  "ports"  from  the  CLI.  For  example,  a 
program  which  reads  text,  justifies  and  paginates  it,  and  then 
writes  it  onto  an  output  device,  could  be  organized  to  read 
from  "S0URC1"  and  write  to  "SINK3."  Before  the  program  is 
started  the  user  may  issue  the  CLI  commands  to  assign  the  paper 
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tape  reader  (or  the  teletype,  or  a  disk  file,  or  the  card 
reader  through  the  IBM  1800  copy  port,  etc.)»  to  "S0URC1"  and 
the  paper  tape  punch  (or  the  teletype,  a  disk  file,  etc.)  to 
"SINK3."  Of  course,  if  a  program  has  a  specific  task  to  perform, 
the  use  of  device- independent  features  will  not  usually  be  ad¬ 
vantageous.  In  such  a  case,  the  program  may  call  directly  on  the 
specific  device  desired.  Device  independence  is  useful  mostly 
in  general  service  programs  and  programs  in  which  a  choice  of 
I/O  ports  is  most  conveniently  made  at  run  time. 

Unfortunately,  the  attempted  device  independence  is  not 
complete.  Disk  files  operating  as  sources  or  sinks  must  first  be 
opened-in  or  -out  before  information  may  be  read  from  or  written 
into  them.  Thus,  at  the  time  a  user  assigns  the  disk  to  a  port, 
he  should  also  open  the  appropriate  file  through  the  CLI  commands 
for  this  purpose.  After  a  program  has  finished  using  a  file  it 
should  be  closed,  again  by  the  appropriate  CLI  command.  Various 
disk  errors  may  also  occur  (cf . ,  Section  2. 5. 2. 5),  so  that  a 
user  who  anticipates  that  a  disk  file  may  be  assigned  to  a  port 
should  provide  for  this  possibility  by  setting  up  an  appropriate 
disk  error-handling  routine. 

2.1.2  System  Communication  Area 

The  system  communication  area  is  a  set  of  locations  in  low 
core  through  which  the  user  accesses  L0C0SS  subroutines  and 
variables.  Most  of  the  system  subroutines  have  the  address  of 
their  entry  points  in  this  area.  For  example,  to  punch  an 
alphabetic  character  on  tape,  a  program  calls  the  appropriate 
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subroutines  indirectly  through  location  37  (octal),  thusly: 

"JMS  I  37".  This  "absolute  transfer  vector"  type  of  access 
to  system  subroutines  insulates  user  programs  from  the  vaga¬ 
ries  of  system  changes,  so  that  everyone  need  not  change  his 
program  when  a  minor  system  change  is  made. 

A  symbolic  tape  (and  disk  file)  define  all  the  communica¬ 
tion  area  locations  as  ins  true t i on- 1  ike  mnemonics.  Using  the 
definitions  from  this  tape,  then,  in  the  previous  example  the 
user  may  write  only  "PCHA"  since  the  tape  makes  the  definition 
"PCHA  JMS  I  37".  Thps  by  making  the  LOCOSS  symbols  the  first 
tape  in  an  assembly  the  user  may  have  symbolic  access  to  the 
communication  area.  The  tape  also  contains  the  symbolic  opera¬ 
tion  codes  for  the  IBM  1800-PDP-7  interface.  (See  the  disk  and 
copy  port  sections  for  use.)  Note  that  this  tape  should  come 
before  any  user  tapes  in  an  assembly  since  it  "FIX"es  the  symbol 
table  so  that  none  of  the  l.OCOSS  definitions  appear  in  the  user's 
symbol  table  printout.  A  listing  of  this  tape  appears  in 
Appendix  A. 

In  addition  to  indirect  jump  and  subroutine  jump  entries 
in  the  communications  area,  there  are  also  directly  referenced 
system  variables.  Some  of  these  variables  may  be  set  by  the 
user  to  control  the  action  of  some  subroutines.  For  example, 
the  variable  LEDING  (location  130  octal)  contains  the  ASCII 
character  which  is  used  to  replace  leading  zeros  during  the 
output  of  a  decimal  or  octal  number.  To  indicate  that 
the  system  routines  should  output  a  number  with  leading 
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blanks,  the  user  puts  an  ASCII  blank  into  the  indicator  location 

LAC  (240) 

DAC  LEDING 

The  generalized  sources  and  sinks  are  also  addressed  in 
this  fashion  and  may  be  set  directly  by  a  user  program.  The 
CLI  instructions  for  assigning  specific  devices  to  the  ports 
puts  an  effective  JMS  into  these  locations,  so  that  the  normal 
method  of  using  these  ports  is  via  an  execute  instruction;  for 
example,  XCT  SINK2.  There  are  three  each  of  the  generalized 
sources  and  sinks. 

Other  directly  addressed  locations  contain  pointers  to 
information  within  LOCOSS  which  may  be  of  possible  interest 
to  the  user.  For  example,  RDRLOC  contains  the  location  of 
the  system  buffer  control  block  (BCB)  for  the  paper  tape  reader. 
If  a  user  wishes  to  provide  a  larger  reader  buffer  than  is  pro¬ 
vided  by  the  system,  or  wishes  to  play  games  with  the  informa¬ 
tion  after  it  enters  the  buffer,  he  may  choose  to  change  the 
BCB  through  RDRLOC. 

2.1.3  Operating  Procedures 

Start-Up .  Two  procedures  are  available  for  loading  LOCOSS. 
If  the  IBM  1800  is  not  prepared  to  service  PDP-7  requests,  the 
system  must  be  loaded  entirely  from  the  tape  labeled  L0C0SS-3 
(found  in  the  trays  of  system  tapes).  Place  it  in  the  reader, 
set  the  ADDRESS  switches  to  17720  octal  and  press  READ-IN.  The 


tape  will  proceed  to  load  itself  and  start  automatically.  A 
halt  at  location  17756  indicates  a  checksum  error  on  reading 
the  tape.  An  adventuresome  user  may  press  CONTINUE  to  ignore 
the  error,  but  the  recommended  procedure  is  to  start  over. 

The  above  sequence  will  be  referred  to  as  "CORE  IMAGE  LOADING", 
or  the  CIL  procedure. 

If  the  IBM  1800  is  prepared  to  service  the  PDP-7,  the 
following,  faster,  sequence  may  be  followed.  Place  the  tape 
labeled  "LOCOSS  BOOTSTRAP"  in  the  reader,  set  the  ADDRESS 
switches  to  17777  octal  and  press  READ-IN.  This  short  tape 
loads  LOCOSS  from  the  2310  disk  and  starts  it  automatically. 

A  halt  at  location  17642  indicates  a  checksum  error,  and  may 
be  ignored  by  a  CONTINUE.  A  halt  at  location  17772  indicates 
a  disk  error  in  the  loading  procedure,  in  which  case  the  error 
code  is  in  the  accumulator. 

Loader  Area.  Both  of  these  methods  of  loading  use  non- 
DEC-standard  loaders  and  preempt  the  normal  loader  area.  If 
the  user  wishes  to  use  the  RIM  or  FF  loaders,  he  must  load 
them  via  the  normal  tape  procedures  or  use  the  LOCOSS  command 
"RIM"  to  load  them  from  the  disk.  When  LOCOSS  (or,  in  fact, 
any  program)  is  loaded  from  the  disk,  the  loader  used  occupies 
locations  17600-17777.  Unless  this  copy  of  the  loader  is 
destroyed  it  may  be  reused  directly  by  any  program.  The  normal 
method  for  loading  new  programs  from  the  disk  is  via  subroutine 
LOAD.  If,  however,  a  user  program  is  not  LOCOSS - compat ib 1 e 
(and  perhaps  destroys  LOCOSS),  it  may  use  the  loader  in  high 
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core.  It  should  also  be  noted  that  copies  of  the  two  routines 
DSKERR  and  DISK  are  included  in  the  loader  and  may  be  called 
by  the  user  for  non-standard  uses  (e.g.,  when  the  LOCOSS 
routines  are  not  in  core).  Details  on  these  procedures  may  be 
obtained  from  the  loader  write-up.* 

As  stated  above,  the  loading  procedures  for  LOCOSS  produce 
an  automatic  start.  The  system  may  be  completely  restarted  at 
location  22  (octal)  either  manually  or  by  transferring  control 
from  a  program.  Location  22  contains  a  CAF  (Clear  All  Flags) 
instruction  so  that  all  I/O  will  be  aborted,  the  display  stopped, 
and  the  dataphone  hung  up.  transferring  control  from  a  program 
to  location  23  will  restart  the  system  without  affecting  the 
display  or  dataphone  run  status. 

Core  Storage.  The  resident  section  of  LOCOSS  occupies 
locations  0-4377  octal,  and  the  loaders  occupy  locations  17600- 
17777  so  that  the  user  area  is  4400-17577.  If  the  user  wishes 
to  use  the  character  generator  or  dataphone  routines  he  must 
load  them  independently  into  high  core. 

Since  the  display  requires  storage  in  the  lower  half  of 
core  for  a  push-down  stack,  locations  4370-4377  of  LOCOSS  are 
reserved  for  this  purpose,  providing  a  four-level  subroutine 
capability  before  overflowing  into  the  normal  user  area  at 

*  Brender,  R.F.,  Frantz,  D.R.,  Foy,  J.L.  Jr.,  and  Schunior, 

T . W . ,  Speciali zed  System  Software  for  Interacting  DEC  PDP -  7 
and  IBM  1800,  Technical  Report  11,  Concomp  Project,  University 
of  Michigan,  Ann  Arbor,  October  1968. 


4400.  Of  course,  the  user  may  also  choose  to  establish  the 
push-down  area  anywhere  else  in  his  section  of  lower  core.. 

Locations  3  and  6  are  available  to  all  programs  as 
volatile,  temporary  storage  locations.  Both  locations  are 
saved  and  restored  by  the  interrupt  service  program  so  that 
they  are  available  to  inte r rupt - time  as  well  as  task-time 
routines.  In  general,  any  call  to  a  LOCOSS  subroutine  will 
result  in  the  destruction  of  these  locations.  Also,  any  call 
to  a  LOCOSS  subroutine  will  result  in  the  destruction  of  the 
active  registers  (AC,  MQ,  and  L)  except  as  noted  in  the  specific 
calling  sequences.  Index  registers  16  and  17  are  reserved  for 
system  use,  but  registers  10-15  are  available  to  the  user. 

The  user  has  access  to  the  reader  and  the  punch  buffer 
control  blocks  in  LOCOSS  through  locations  RDRLOC  and  PCHLOC 
in  the  communications  area.  He  may  change  these  blocks  to 
point  to  a  larger  area  in  user  core  if  he  so  desires,  but 
before  completion,  the  program  should  restore  these  blocks 
to  their  former  state,  either  directly  or  by  reloading  LOCOSS. 

In  summary,  while  operating  under  LOCOSS  the  locations 
that  the  user's  program  may  reference  are:  3,5,10-15,  the 
communications  area  (about  24  to  130),  the  reader  and  punch 
buffer  control  blocks,  4370-17577,  and  selected  portions  of 


the  loaders. 
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Run-Timc  Conventions.  Since  most  I/O  is  performed  under 
interrupt  control,  normal  operation  is  with  interrupts  on,  al¬ 
though  interrupts  may  be  turned  off  for  short  periods  to  per¬ 
form  delicate  operations.  The  interrupts  normally  handled  by 
the  resident  system  are  keyboard,  teleprinter,  reader,  punch, 
and  clock.  When  the  dataphone  routines  are  in  core  and  initia¬ 
lized,  the  system  will  handle  dataphone  transmit  and  receive 
interrupts.  When  the  display  character  routines  are  in  core, 
they  will  handle  the  external  stop  and  manual  interrupts.  All 
other  interrupts  will  cause  a  halt.  Thus  the  user  should  ensure 
that  the  handler  for  each  interrupt  that  may  occur  is  in  core 
and  initialized  through  subroutine  INTABL. 

Users  should  acquaint  themselves  with  the  philosophy  of 
multiprogramming  and  then  consider  the  use  of  BUSY  exit  in  the 
middle  of  very  long  tasks  or  in  the  case  of  blocking  conditions. 
A  BUSY  enables  the  appearance  of  parallel  processing,  allows 
other  tasks  to  gain  control  for  a  time,  and  avoids  "lock-outs" 
of  CPU  control.  The  normal  method  of  ending  a  program 
is  via  a  "DELETE"  exit,  rather  thar  a  halt.  This  allows 
all  buffered  I/O  to  terminate  normally. 

Error  Messages,  Error  messages  report  on  intolerable 
conditions  within  the  executive.  When  one  of  these  con¬ 
ditions  is  detected,  all  task  processing  is  halted,  a  CAF 
instruction  is  given,  the  error  number  is  printed,  preceded 
by  the  letters  "dERR,"  and  LOCOSS  is  completely  reinitialized. 
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If  the  same  error  is  encountered  twice  in  succession,  the  com¬ 
puter  will  halt  with  the  error  number  in  the  AC.  (This 
feature  protects  against  looping  before  an  error  message  may 
be  printed.)  Pressing  CONTINUE  in  this  case  produces  the  same 
effect  as  starting  at  location  22.  The  following  is  a  list  of 
the  error  numbers. 

000001  There  was  no  room  in  the  task  queue  when  some 
program  called  INSERT,  SUBTSK,  BUSY,  or  WAIT. 

000002  There  was  no  room  in  the  event  table  when  some 
program  called  CREATE. 

000003  A  disk  error  occurred  on  a  call  to  DISK,  DSKGET,  or 
DSKPUT  when  no  previous  call  or  DSKERR  had  been 
made.  Location  20  (octal)  contains  the  error 
number . 

000004  There  was  no  room  in  the  clock  table  when  some 
program  called  CLOCK. 

2XXXXX  A  CAL  trap  occurred  from  location  XXXXX. 

Operating  parameters.  In  the  current  system  there  is 
room  for  ten  decimal  tasks,  eight  events,  and  four  simulated 
user  clocks.  The  reader  and  punch  buffers  are  both  of  size 
ten  and  may  be  "packed."  The  teleprinter  buffer  has  size 
fifteen  and  may  be  packed.  The  keyboard  buffer  will  accept 
seventy-four  characters. 
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2.2  Multiprogramming 

2.2.1  Basic  Philosophy 

Multiprogramming  is  an  organization  of  system  resources 
which  aids  in  the  conceptualization  of  some  programs  by  enabling 
the  user  to  start  more  than  one  job  or  line  of  execution  at  a 
time.  The  LOCOSS  multiprogramming  system  also  includes  features 
to  facilitate  intra-program  communication  and  resource  allocation. 
All  of  LOCOSS  I/O  uses  the  multiprogramming  system  to  great  ad¬ 
vantage,  although  the  user  may  run  programs  under  LOCOSS  in 
almost  complete  ignorance  of  the  system  organization.  The 
following  is  a  summary  of  system  philosophy  and  a  tutorial  in 
system  use. 

In  general,  a  section  of  code,  a  subroutine,  will  be  called 
a  program.  It  usually  operates  on  some  parameters  to  produce 
a  desired  result.  An  invocation,  or  instance,  of  a  program, 
with  parameters,  is  called  a  task .  In  a  multiprogramming  en¬ 
vironment,  several  tasks  may  be  operating  in  parallel;  i.e., 
if  there  were  more  than  one  processor,  these  tasks  would  be 
executing  simultaneously.  With  one  processor  these  tasks  are 
executed  serially,  but  at  certain  points  control  is  switched 
between  one  task  and  another  so  that  each  gets  a  portion  of 
the  serial  time,  and  the  total  state  of  the  system  after  many 
such  task- swi tch ings  approximates  the  parallel  processor  case. 

In  timesharing  systems,  this  switching  takes  place  after  a 
given  amount  of  time.  In  LOCOSS,  the  switching  takes  place  only 
when  (but  not  always  when)  control  is  returned  to  the  executive 
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(e.g.,  I/O  calls,  event  control  calls,  etc.)  . 

In  general,  once  a  section  of  code  starts  execution  as  a 
task,  it  will  change  itself  and  the  data  it  is  working  on  so 
that  it  must  proceed  to  its  conclusion  completely  before  being 
able  to  be  restarted  as  another  task.  Since  several  tasks  may 
wish  to  call  the  same  program  at  once,  that  program  must  have 
some  way  of  indicating  its  readiness  to  start  functioning  as  a 
task.  Taking  advantage  of  the  subroutine  calling  structure  of 
the  PDP-7  we  will  let  the  entry  point  of  a  program  signal  the 
attribute  of  enterab i 1 i ty  .  If  the  program  is  ready  to  begin 
executing  as  a  task,  its  entry  point  will  be  zero.  If  it  is 
not  able  to  start  executing  as  a  new  task,  its  entry  point 
will  be  nonzero.  Since  a  call  to  a  subroutine  automatically 
makes  the  entry  point  non-zero,  all  that  is  required  for  a  pro¬ 
gram  at  the  end  of  one  execution  of  a  task  to  indicate  its 
readiness  to  begin  another  task  is  to  zero  its  entry  point 
before  returning.  For  example,  a  task  which  returns  to  its 
caller  might  appear  as: 


SUB,  0 


/first  executable  instruction 


LAC  SUB 
DAC  TEMP 
DZM  SUB 
JMP  I  TEMP 


/save  return  pointer 
/ready  to  restart 
/ return  to  caller 


A  task  may  start  up  other  tasks  in  two  ways.  The  first 
is  by  starting  a  parallel  line  of  execution  by  calling  system 
subroutine  INSERT.  After  having  been  started,  the  second 
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task  will  not  in  general  depend  on  or  be  related  to  the  first, 
or  vice-versa.  They  may  be  completely  independent.  As  an 
option  for  INSERTing  tasks  which  are  known  always  to  be  re¬ 
enterable,  the  call  to  INSERT  may  indicate  that  control  is  to 
be  transferred  directly  to  the  indicated  entry  point  rather 
than  transferring  control  as  a  subroutine  call;  i.e.,  entry  will 
be  via  JMP  rather  than  JMS,  and  enterability  will  not  be  checked. 

The  second  method  of  starting  a  task  is  to  call  on  it  as 
a  sub t as k  by  calling  system  subroutine  SUBTSK.  A  program  called 
as  a  subtask  is  expected  to  accomplish  some  action  and  then 
return  to  its  caller.  The  calling  task  remains  dormant  until 
its  subtask  finishes,  and  then  regains  control  upon  return  from 
the  subtask.  A  sul task  in  turn  is  a  task  and  may  start  other 
tasks,  and  so  forth. 

When  a  request  is  given  to  the  system  to  start  a  task, 
there  are  usually  other  similar  outstanding  requests.  These 
requests  are  kept  in  the  TASK  QUEUE  until  such  time  as  these 
tasks  may  be  started.  A  task  is  added  to  the  end  of  the  queue 
so  that  all  other  outstanding  tasks  are  started  first  (if  they 
are  enterable).  This  feature  allows  the  semblance  of  parallel 
processing  Eventually  a  request  comes  to  the  top  of  the  queue 
for  consideration.  If  a  program  is  not  enterable,  the  request 
goes  to  the  end  of  the  queue  to  be  tried  again  later.  When  a 
program  is  enterable,  the  information  regarding  its  call  is 
removed  from  the  queue  and  the  call  is  made  as  if  it  came  direct¬ 
ly  from  the  calling  task,  or,  in  the  case  of  an  INSERTed  task, 
as  if  it  were  starting  anew. 
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When  a  task  teaches  a  temporary  impasse,  such  as  a  wait 
for  input  or  a  similar  occurrence  over  which  it  has  little  con¬ 
trol,  it  should  take  a  BUSY  exit,  i.e.,  it  should  return  to 
the  executive  and  give  some  other  task  a  chance  to  execute 
while  the  blocking  condition  clears  up.  The  executive  will  put 
information  regarding  the  busy  task  at  the  end  of  the  queue 
and  return  to  that  task  after  the  others  in  the  queue  have  had 
their  chance  to  execute.  The  task  can  then  check  the  condition 
and  either  go  on  or  return  itself  to  the  queue  again  by  another 
BUSY  exit. 

When  an  independent  line  of  execution  (i.e.,  one  which  is 
not  a  subtask,  but  was  started  by  an  INSERT)  finishes,  it  need 
not  return  to  a  calling  task  but  may  rather  return  control  to 
the  executive  by  a  DELETE  exit.  A  task  which  was  INSERTed  as 
a  JMS  entry  may  also  return  in  the  normal  way.  Both  methods  of 
return  have  the  same  effect— removing  the  task  from  the  active 
roll.  The  task  should  of  course  zero  its  entry  poi  t  before 
the  exit.  Note  that  if  a  program  returns  as  if  it  were  called 
via  JMS,  first  zeroing  its  entry  point  (as  in  the  example  above), 
it  may  be  called  as  a  subroutine  or  a  subtask,  or  inserted  as 
an  independent  task. 

2.2.2  Event  Contro 1 

In  a  multiprogramming  system  with  independent  lines  of 
execution  there  sometimes  exists  the  problem  of  coordinating 
parallel  tasks.  Two  otherwise  essentially  independent  tasks 
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may  need  to  signal  each  other  that  certain  points  in  operation 
have  been  reached,  since  one  may  have  to  wait  until  the  other 
has  finished  some  processing.  In  particular,  it  would  be  dif¬ 
ficult  to  ensure  that  the  passing  of  parameters  to  an  indepen¬ 
dent,  INSERTed  task  had  taken  place  properly  if  there  were  no 
task-task  means  of  communication. 

Events  are  offered  to  resolve  this  problem.  Events  are 
extra-task  entities  which  a  task  may  CREATE  for  some  purpose  as 
above.  Each  created  event  has  a  unique  name  (a  number)  which 
may  be  given  to  other  tasks  for  reference.  The  task  may  then 
take  a  WAIT  exit,  that  is,  return  itself  to  the  queue  until  the 
given  event  has  occurred.  This  task  in  the  queue  is  not  re¬ 
activated  until  the  event  has  occurred.  One  of  the  daughter 
tasks,  in  the  meantime,  has  the  responsibility  of  giving  the 
SIGNAL  that  the  event  has  been  completed.  After  this,  the 
next  time  the  waiting  task  comes  up  for  consideration  in  the 
queue,  it  will  be  reactivated  and  can  continue  safe  in  the  as¬ 
surance  that  the  blessed  event  is  properly  cared  for. 

In  view  of  the  foregoing  discussion,  we  may  make  the 
following  general  comments  about  system  operation.  Most  user 
programs  will  be  written  as  at  least  one  task.  Thus,  a  stan¬ 
dard  method  of  starting  a  program  when  LOCOSS  is  in  core  is: 
first  load  the  user  program  tape  and  start  execution  at  loca¬ 
tion  22  (either  by  a  START  22  on  the  program  tape  or  by  a 
PAUSE  on  the  tape  followed  by  manually  pressing  the  START  key 
with  the  ADDRESS  switches  at  22).  Either  way,  starting  at  22 
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initializes  LOCOSS.  Then  type  "(ESC)  INS  XXXXX"  which  is  the 
CLI  command  to  insert  a  task  into  the  queue  at  location  XXXXX, 
the  entry  point  of  the  user's  task.  Recall  that  this  entry 
point  should  be  zero  for  the  task  to  be  started.  If  entry  is 
to  be  made  via  JMP,  the  proper  command  is  "(ESC)INS  4XXXXX". 

If  the  user  task  does  any  I/O,  it  should  be  recalled  that, 
with  high  probabil ity,  some  output  buffer  will  eventually  fill 
or  some  input  buffer  will  be  empty.  If  either  of  these  condi¬ 
tions  occurs,  the  I/O  task  segment  will  take  a  BUSY  exit. 

That  is  to  say,  every  other  task  in  the  queue  will  be  given  a 
chance  to  execute  before  control  is  returned  to  the  BUSYed 
task.  If  there  is  only  one  task  in  existence,  there  is  no 
problem.  However,  when  there  is  more  than  one  line  of  control, 
care  should  be  taken  that  any  I/O  referencing  is  coordinated 
among  them  so  that  two  tasks  will  not  be  calling  an  I/O  sub¬ 
routine  at  the  same  time  with  an  undesired  interleaving  of 
the  transferred  information  and  loss  of  correct  return  points 
from  the  I/O  program. 

2  2.3  Subroutine  Calls 
SUBTSK 

Purpose:  To  put  a  task  into  the  queue  and  to  relinquish 

control  of  the  current  task  until  the  subtask 
is  finished. 

Calling  Sequence:  AC  =  argument 


SUBTSK 
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Calling  Sequence  (cont'd): 

ROUTIN' 

/optional  arguments 


RETURN,  - 

ROUTIN  is  the  address  of  the  task  to 
s  tarted 

RETURN  is  the  location  to  which  control 
is  transferred  when  the  task  at 
ROUTIN  is  finished. 


Optional  arguments  are  to  be  consistent  with  the  called 
task's  expectations.  When  ROUTIN  is  given  control  the  AC  is 
the  same  as  upon  the  call,  although  the  MQ  register  may  have 
been  destroyed.  The  entry  point  ROUTIN  itself  contains  the 
address  of  the  word  after  ROUTIN  in  the  calling  sequence  above, 
as  if  the  call  were  a  direct  JMS  from  the  location  containing 
ROUTIN,  so  that  the  return  sequence  in  the  first  example  in 
Multiprogramming  (above)  may  be  used.  Upon  entry  to  SUBTSK 
interrupts  may  be  on  or  off. 

INSERT 

Purpose:  To  insert  an  independent  task  into  the  queue. 

Calling  Sequence:  IOF 

AC  =  argument 
INSERT 

ROUTIN  /  or  LAW  ROUTIN  or  400000+ 

ROUTIN  (See  option  below.) 


RETURN, 


ION 
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ROUTIN  is  the  entry  point  of  the  task  to  be  started.  If 
"LAW  RUUTIN"  is  used  in  the  call,  entry  is  made  via  JMP  rather 

than  JMS.  RETURN  is  the  point  to  which  control  is  returned 

immediately  after  the  task  is  entered  into  the  queue.  When 
task  ROUTIN  is  given  control,  the  AC  is  the  same  as  upon  the 

call  although  the  MQ  may  have  been  destroyed.  In  a  JMS  call, 

location  ROUTIN  itself  is  set  nonzero  to  indicate  that  the 
task  is  not  enterable.  Such  independent  tasks  may  relinquish 
control  by  DELETE  or  by  returning  as  in  SUBTSK.  Both  methods 
return  control  to  the  same  location  in  the  Multiprogramming 
monitor.  A  task  entered  via  JMS  should  zero  its  entry  point 
before  either  method  of  return. 

BUSY 

Puriose:  To  return  the  currently  executing  task  to  the 

queue  to  be  reactivated  later. 

Calling  Sequence:  AC  =  any 

BUSY 

RETURN,  - 

Control  is  returned  to  location  RETURN  when  the  task  next 
comes  under  consideration  in  the  queue.  The  AC  is  saved  and 
restored  around  the  call  to  BUSY  by  the  system.  Interrupts 
may  be  on  or  off  upon  entry.  Return  is  made  with  interrupts 


on . 
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DELETE 

Purpose:  To  return  control  to  executive  when  an  indepen¬ 

dent  line  of  execution  is  finished. 

Calling  Sequence:  DELETE 

Interrupts  may  be  on  or  off  upon  entry. 

CREATE 

Purpose:  To  obtain  a  unique  event  number  for  reference 

use. 

Calling  Sequence:  IOF 

CREATE 
RETURN,  - 

When  control  is  returned  to  location  RETURN  the  AC  contains 
a  unique  event  number  for  reference  in  WAIT  or  SIGNAL  calls. 

WAIT 

Purpose:  To  return  the  currently  executing  task  to  the 

queue  until  a  given  event  occurs. 

Calling  Sequence:  AC  =  event  number  /ION  or  IOF 

WAIT 

RETURN,  -  /with  ION 

After  the  event  corresponding  to  the  reference  number  in 
the  AC  occurs,  a  transfer  to  location  RETURN  is  scheduled  in 
the  task  queue.  If  the  event  has  already  occurred  or  if  there 
is  no  event  corresponding  to  the  reference  number,  return  is 


i mmedi ate . 
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SIGNAL 

Purpose:  To  indicate  that  a  given  event  has  occurred. 

Calling  Sequence:  AC  =  event  number  /IOF 

SIGNAL 

RETURN,  -  /ION 

The  event  corresponding  to  the  reference  number  is  marked 
as  having  occurred  and  all  tasks  waiting  for  the  event  will  be 
reactivated  as  their  turn  comes  in  the  queue.  No  action  occurs 
if  the  event  has  already  taken  place  or  if  the  event  referenced 
is  nonexistent. 

CLEARE 

Purpose:  To  reinitialize  all  events  and  event  handling 

Calling  Sequence:  IOF 

CLEARE 
RETURN,  - 

The  next  event  to  be  created  will  have  number  one  (1). 
CLEARQ 

Purpose:  To  clear  the  task  queue  of  all  outstanding  tasks. 

Calling  Sequence:  IOF 

CLEARQ 
RETURN,  - 

After  execution  of  CLEARQ  the  only  line  of  execution 
(the  active  task)  will  be  the  one  which  called  CLEARQ. 
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2.3  Command  Language  Interpreter 

The  Command  Language  Interpreter  (CLI)  is  a  portion  of 
the  LOCOSS  keyboard  routines  which  provides  the  user  with  a 
measure  of  control  over  the  immediate,  real-time  state  of  the 
system.  Since  the  CLI  is  an  interrupt - 1 ime  package,  a  command 
line  may  be  entered  at  any  time,  independently  of  the  state  of 
the  user  program. 

A  command  line  is  a  keyboard  input  line  which  has  as  its 
first  character  an  ESC  (Cont ro 1  -  Shi f t  K) .  Thus  the  line  is 
subject  to  the  same  editing  as  other  keyboard  input.  Once  an 
ESC  is  typed  at  the  beginning  of  a  line  it  may  not  be  deleted 
by  LEFTARROW;  thus,  the  line  will  be  dispatched  to  the  CLI 
unless  RUBOUT  is  typed.  When  the  carriage  return  is  entered, 
finishing  the  command,  a'.l  task  processing  is  stopped  until 
the  command  has  been  carried  out  successfully,  at  which  time 
the  CLI  types  "DONE."  If  any  key  is  struck  before  this  time 
the  command  is  aborted.  If  a  command  is  ill-formed,  the  CLI 
will  type  back  "WHAT?"  and  ignore  it.  When  echoing  is  on 
(see  Section  2.5. 2.4)  an  is  echoed  when  ESC  is  typed. 

There  are  three  groups  of  commands:  general  control, 
disk  file  control,  and  device  assignment.  The  format  for 
device  assignment  commands  is  given  separately  below.  For 
the  first  two  groups,  a  command  is  a  three-letter  mnemonic, 
possibly  followed  by  numeric  parameters  separated  by  non¬ 
digit  character  strings  (e.g.,  space),  optionally  followed 
by  any  character  string  (for  comment  recording  purposes). 
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Numbers  given  to  the  CLI  are  octal  or  decimal  depending  on  the 
command  type.  Only  the  eighteen  low-order  bits  of  any  number 
are  used.  After  the  first  three  characters  of  an  input  line, 
all  nondigit  characters  are  ignored  except  as  terminators  of 
numbers . 

2.3.1  General  Commands 

ATN 

ATN  sends  an  attention  character  over  the  dataphone  (if 
it  can),  by  calling  subroutine  DFNATN.  The  CLI  message  "DONE" 
printed  at  the  command  termination  means  merely  that  the 
transmission  has  been  scheduled,  not  necessarily  that  it  has 
been  started  or  completed. 

DDT 

DDT  causes  control  to  be  transferred  to  location  16000 
(octal).  Control  may  be  returned  to  the  program  and  LOCOSS 
by  transferring  control  from  DDT  to  location  2,  i.e.,  by 
typing  "two  prime"  (2').  DDT  should  be  told  to  watch  the 
teleprinter  flag  by  giving  it  the  TTY$  and  STI0C$  command  and 
by  setting  the  variable  TTYF$  to  1. 

DAT 

DAT  initializes  the  hardware  and  software  for  dataphone 
communications;  that  is,  it  sets  "terminal  ready"  on  the  data 
set  and  initializes  the  dataphone  routines  by  calling  DFNI. 

This  command  must  be  given  before  incoming  or  outgoing  calls 
are  made  on  the  data  set  and  may  be  repeated  thereafter  to  clear 
up  any  bad  messes  without  hanging  up  the  set. 
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DMP 

DMP  takes  one  or  two  octal  arguments.  If  there  are  two 
arguments,  all  the  core  locations  between  and  including  the 
two  locations  given  by  the  arguments  are  printed  on  the  tele¬ 
type,  in  octal,  eight  words  per  line,  with  appropriate  labeling. 
If  only  one  argument  is  given,  only  that  one  location  is  dumped. 
For  example,  DMP  10  17  will  dump  all  locations  between  and 
including  10  and  17  (octal). 

EC  F 

ECF  causes  echoing  to  be  turned  off. 

ECN 

ECN  causes  echoing  to  be  turned  on.  (See  the  discussion 
under  the  keyboard  routines.)  The  original  state  of  the  system 
is  with  echoing  on. 

HEL 

HEL  merely  types  back  this  version's  assembly  data  to  as¬ 
sure  an  anxious  user  that  the  CLI,  at  least,  is  still  listen¬ 
ing  to  him. 

HSR 

HSR  starts  the  high-speed  tape  reader  after  it  has  been 
stopped  by  an  XOFF  or  end-of-tape  condition,  or  if  it  has  never 
been  started.  This  command  should  not  be  given  if  none  of  these 
conditions  exist.  (See  the  high-speed  reader  routires.) 


INS  takes  one  or  two  octal  arguments.  The  first  is  the 
address  of  a  task  to  be  entered  into  the  task  queue,  and  the 
second,  if  any,  is  the  argument  to  be  passed  in  the  AC  to  the 
task  when  it  is  scheduled.  If  there  is  no  second  argument,  a 
zero  is  passed  to  the*  task,  e.g.,  INS  4400  15. 

RES 

RES  resumes  task  processing  at  the  point  at  which  it  was 
interrupted  by  STP.  If  no  STP  was  given  since  the  last  RES, 
a  second  RES  has  no  effect. 

RST 

RST  completely  restores  the  pristine  state  of  the  system 
(probably).  (See  system  routine  RESET.) 

STO 

STO  takes  two  or  more  octal  arguments  The  first  is  con 
sidered  as  a  location  in  which  to  store  the  second  argument. 
Additional  arguments  are  stored  in  successive  locations.  For 
example,  STO  4500  123  has  the  effect  of  putting  a  1  into 
location  4500,  a  2  into  4501, and  a  3  into  4502. 

STP 

STP  stops  all  task  processing  until  the  RES  command  is 
given.  The  CLI  is  still  available  during  task  suspension 
(most  importantly  for  DMP  and  STO).  A  second  STP  before  an 
RES  is  treated  as  an  illegal  command. 
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1  A  B 

AB  takes  one  decimal  argument  and  uses  it  to  set  the 
syst*'”  variable  TABCNT;  that  is,  it  sets  the  tab  spacing. 

I . G . ,  TAB  15  will  set  tab  stops  at  decimal  16,  31,  46,... 

2.3.2  Disk  File  Control  Commands 

The  ,‘ollowing  commands  provide  direct  communication  with, 
and  «ontrol  of,  the  disk  file  servicing  routine  in  the  IBM 
1800  through  the  system  subroutine  DISK.* 

With  the  exception  of  LOD  and  RIM,  they  all  print  the 
return  from  the  disk  routines  indicating  success  or  failure, 
and  in  case  of  failure  even  LOD  and  RIM  print  the  failure 
number.  A  success  return  is  indicated  by  printing  000xxx 
(octal)  where  xxx  is  the  returned  value.  A  failure  return 
is  indicated  by  006xxx  where  xxx  is  the  disk  error  code. 

A  CL  I  call  on  DISK  should  not  be  issued  if  a  program  is 
in  the  midst  of  conversing  with  the  disk,  since  no  effort 
has  been  made  to  make  the  routines  reentrant.  A  CLI  call  will 
not  disturb  the  user  disk  error  return. 

CLI 

Close  the  currently  opened  input  file. 


*  Brender,  R.F.,  Frantz,  D.R.,  Foy,  J.L.  Jr.,  and  Schunior, 
T .  IV .  ,  Specialized  System  Software  for  Interacting  DEC 
PDP- 7  and  I BM  1800,  Technical  Report  11,  Concomp  Project, 
University  of  Michigan,  Ann  Arbor,  October  1968. 
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CLO 

Close  the  currently  opened  output  file. 

CLR 

Close  any  opened  input  or  output  files. 

CRE 

CRE  takes  one  decimal  argument  and  creates  a  file  with 
that  number. 

DES 

DES  takes  one  decimal  argument  and  destroys  the  file  with 
that  number.  No  verification  of  the  number  is  sought  so  this 
command  should  be  used  carefully. 

INT 

INT  takes  one  or  two  octal  arguments  and  uses  them  as 
parameters  for  a  direct  call  on  the  system  subroutine  DISK. 

The  first  argument  is  the  disk  operation  code  and  the  second 
is  a  file  number  or  character.  The  second  argument  need  not 
be  present  x  f  not  applicable  (e.g.,  in  a  CLOSE  call)  and  is 
defaulted  to  zero. 

LOP 

LOD  takes  one  decimal  argument  and  uses  it  as  the  para¬ 
meter  for  a  call  on  system  subroutine  LOAD;  i.e.,  the  ad¬ 
dressed  file  is  loaded  into  core.  If  a  disk  error  occurs 
during  loading,  the  disk  error  number  is  printed  out  and  the 
loading  is  aborted. 
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0 1 T 

OIT  takes  one  decimal  argument  and  opens  that  file  for 
input,  translated. 

OIU 

OIU  takes  one  decimal  argument  and  opens  that  file  for 
input,  untranslated. 

OPT 

OOT  takes  one  decimal  argument  and  opens  that  file  for 
output,  translated. 

OOU 

OOU  takes  one  decimal  argument  and  opens  that  file  for 
output,  untranslated. 

RIM 

RIM  loads  the  READ- IN-MODE  and  FUNNY  FORMAT  loaders  into 
their  proper  positions  in  core  (17600-17777)  from  File  5. 

This  file  is  in  bootstrap  format  and  cannot  be  loaded  by  a 
LOU  command. 

2.3.3  Device  Assignment  Commands 

The  device  assignment  commands  provide  the  link  between 
a  program's  references  to  generalized  SOURCES  and  SINKS  and 
the  actual  devices  used  in  a  particular  "run"  of  a  program 
(see  Section  2.1).  For  example,  the  assembler  is  written 
to  accept  input  from  SOURC1,  and  the  user  directs  the  CLI  to 
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assign  either  the  teletype,  the  tape  reader,  the  IBM  copy  port, 
or  a  disk  file  to  S0URC1  before  the  assembler  starts. 

The  form  of  the  device  assignment  command  is: 

<DEVICE  ASSIGNMENT  COMMANDS:  =  <DEVICE>  <  PORT>  |  <DEV  I CE  >  <MODE> 

<  PORT> 

<DEVICE> : :  =  TTY | TAP | DSK | ICY | DFN  |  DSP | DMY 
<M0DE  > : :  =  BIN|ALP 

<P0RT> : :  =  SC  1 | SC  2 | SC3 | SKI | SK2 | SK3 

If  no  mode  is  given,  ALP  (alphanumeric)  is  the  default 
case.  Thus,  the  user  may  assign  the  appropriate  input  or  out¬ 
put  routine  for  the  teletypewriter,  paper  tape,  disk,  IBM  copy 
port,  dataphone,  display,  or  dummy  routine,  in  binary  or  al¬ 
phanumeric  mode,  to  one  of  the  system  transfer  vector  locations 
S0URC1,  SOURC  2  ,  S0URC3 ,  SINK1,  SINK\,or  SINK3 .  Any  illegal 
assignments  or  improper  syntax  will  be  greeted  with  "WHAT?" 
and  the  command  will  be  ignored. 

The  following  table  gives  the  legal  assignments  for  devices. 
Blank  entries  indicate  illegal  assignments,  i.e.,  nonsensical 
or  not -ye t - coded  system  functions.  The  other  entries  are  the 
LOCOSS-de fined  assembly  instructions  which  are  inserted  into 
the  source  or  sink  location  For  example,  issuing  the  command 
"(ESC)TTY  SKI"  is  equivalent  to  executing  the  code: 

LAC  (TPRA) 


DAC 


SINK1 
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A  user's  program  may  determine  whether  a  specified  device 
has  been  assigned  to  a  particular  port  by  executing  an  SAD 
instruction,  thusly: 


LAC  S0URC1  /get  S0URC1 

SAD  (RDRA)  /compare  to  RDRA 

-  / SOURC 1  =  RDRA 

-  / SOURC 1  t  RDRA 


i 
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Table  1 

Device  Assignment  Table 


ALPHANUMERIC  PORTS 
Source  Sink 

BINARY 

Source 

PORTS 

Sink 

TPRA 

KBDA 

RDRA 

PCHA 

RDRB 

PCHB 

DSKGET 

DSKPUT 

ICYRDT 

ICYWRT 

DFNRA 

DFNSA 

JMS  17006 

DUMMY 

DUMMY 

DUMMY 

DUMMY 
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2  4  General  Service  Routines 
RESET 

Purpose:  To  reinitialize  the  whole  system. 

Calling  Sequence:  RESET  /ION  or  IOF 

RETURN,  -  /ION 

All  I/O  is  aborted,  and  device  handlers  for  the  keyboard, 
teleprinter,  reader,  punch,  clock,  disk  IBM  1800  copy  port, and 
dataphone  are  initialized  by  the  system  routines.  The  task 
queue  is  emptied  and  event  handling  is  reinitialized.  The 
system  variables  are  reset  to  provide  echoing  and  prompting 
characters  for  keyboard  input,  i.e.,  ECHOSW  =  PRMPTC  =  0. 

The  tab  count  is  set  to  ten  (decimal)  and  LEDTNG  is  set  to 
an  ASCII  zero  (octal  260).  Location  1  is  reset  so  that 
LOCOSS  provides  all  interrupt  dispatching. 

CLOCK 

Purpose:  To  enable  a  timed  return  to  a  section  of  the 

user's  program . 

Calling  Sequence:  IOF 

AC  =  -N  /twos  complement  form 

CLOCK 

JMS  CLKINT  /to  be  XCT'ed 

RETURN,  ION  /AC  contains  address  of 

simulated  clock 
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After  N/60s  of  a  second,  a  clock  interrupt  will  occur  and 
control  will  be  transferred  to  the  user  subroutine  CLKINT  with 
interrupts  off.  This  subroutine  will  be  operating  at  interrupt 
time  so  that  it  must  do  all  its  processing  with  interrupts  off 
and  return  to  the  interrupt  dispatcher  as  soon  as  possible. 
Thus,  all  it  can  do  is  set  some  flags  for  the  user,  INSERT  a 
task,  or  set  another  clock.  Up  to  four  simulated  clocks  can 
be  set  at  any  one  time. 

The  address  returned  in  the  accumulator  by  CLOCK  is  the 
address  of  the  simulated  clock.  This  location  contains  the 
twos  complement  of  the  number  of  l/60s  of  a  second  before  the 
clock  runs  out.  This  number  may  be  changed  at  any  time  before 
the  clock  is  set  to  go  off,  and  in  particular  it  may  be  set  to 
zero,  which  will  disable  the  simulated  clock  should  the  program 
decide  that  the  interrupt  is  no  longer  needed.  When  the  inter- 
rupt-time  routine  is  called,  the  simulated  clock  has  gone  to 
zero  so  that  it  is  no  longer  active.  If  the  i nte rrupt - t ime 
routine  decides  to  reset  a  clock,  it  may  reset  the  timer  which 
called  it  rather  than  make  a  new  call  on  CLOCK.  Warning:  once 
a  clock  has  been  set  to  zero  by  the  user,  as  above,  or  has  been 
allowed  to  remain  at  zero  after  it  has  run  out,  the  address 
given  to  that  clock  should  no  longer  be  used  since  it  may  be 
assigned  to  another  program. 

Example:  The  code  below  will  result  in  the  character  "A" 

being  typed  once  per  second. 


-40- 


IOF 

LAM  -74fl 

CLOCK 

JMS  CLKINT 

DAC  CLKLOC 

DELETE 


CLKLOC,  0 


CLKINT,  0 

LAM  -74+1 

DAC  I  CLKLOC 
INSERT 
TYPE 

EXIT  CLKINT 


TYPE,  0 

LAC  (301) 
TPRA 

DZM  TYPE 
DELETE 


INTABL 

Purpose:  To  change  the  interrupt  handler  for  a  given 

inr.  a  rrupt . 

Calling  Sequence:  LAW  INTNO 

INTABL 
JMS  HANDLR 
RETURN,  - 


HANDLR  is  the  entry  to  the  real-time,  interrupts-of f 
subroutine  which  will  clear  the  associated  flag,  do  the  ne¬ 
cessary  processing,  and  return  to  the  executive  interrupt 
dispatcher,  INTNO  is  the  number  of  the  interrupt  as  given  in 
the  following  table.  The  numbers  below  are  octal. 


/task  entry  point 
/ASCII  "A" 

/type  it 

/make  reenterable 
/return  to  LOCOSS 


/reset  clock  for  another  second 
/insert  the  type  task 

/return  to  real  clock  interrupt 

/handler 


/  =  - 60  Decimal 

/clock  handler 
/address  of  clock 
/return  to  LOCOSS 
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Interrupt  Number 


1 

2 

3 

4 


Device 

Dataphune  Transmit 
Light  Pen 

Vertical  Edge  Flag 
Horizontal  Edge  Flag 


5 

6 
7 

10 

11 

12 

13 

14 


Internal  Stop 
External  Stop 
Dataphone  Receive 
Manual  Interrupt 

Push  Button  Hit 
Tape  Reader 
Tape  Punch 
Keyboard 


15 

17 


Teleprinter 

Clock 


LOAD 

Purpose:  To  load  a  file  from  the  1800  disk  and  start 

it  executing,  or  return  to  the  user,  depending 
on  the  contents  of  the  file. 

Calling  Sequence:  AC  =  file  number  /ION  or  IOF 

LOAD 

ERROR  RETURN  /ION 

SUCCESS  RETURN  /ION 


The  PDP-7  support  routine  must  be  initialized  in  1800 
core  for  this  command  to  have  any  effect.  All  input  files 
should  be  closed  before  calling  LOAD. 

If  the  loading  procedure  produces  an  error  of  some  sort 
(e.g.,  1800  dead,  snarked  bootstrap  specification,  or  no  such 
file)  control  will  be  passed  to  the  error  return  with  the  AC 
containing  the  disk  error  number. 
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The  file  addressed  is  assumed  to  be  in  core  image  format 
with  a  START  or  PAUSE  control  block  at  the  end  of  the  file.* 

If  the  block  is  PAUSE,  control  will  be  returned  to  the  success 
return  with  interrupts  on.  If  the  block  is  START,  control  will 
be  passed  to  the  location  addressed  in  the  START  block  with 
i nt  e  r rup t  s  off. 

R DOC  T 

Purpose:  To  read  and  translate  a  stream  of  ASCII  characters 

into  a  twos  complement,  signed  octal  number. 

Calling  Sequence:  RDOCT 

JMS  INPUT 

ERRET,  - 

NRMRET ,  - 

INPUT  is  the  entry  point  to  a  routine  which  provides  a 
stream  of  ASCII  characters.  For  example,  this  call  may  be  "KRDA," 
which  is  an  effective  JMS.  All  the  characters  read  from  the 
source  stream  up  to  the  first  octal  digit  or  minus  sign  are 
ignored.  \  minus  sign  starts  a  number  and  may  not  be  separated 
from  the  first  digit  by  any  other  character.  If  no  octal  digits 
or  a  minus  sign  are  read  before  a  carriage  return,  control  is 
returned  to  location  ERRET.  When  a  number  is  terminated  (by 
a  non-octal  digit),  control  is  returned  to  location  NRMRET  with 

*  Brender,  R.F.,  Frartz,  D.R.,  Foy,  J.L.  Jr.,  and  Schunior, 

T . W . ,  Speci a  1 i zed  System  Software  for  Interacting  DEC 
PDP -  7  and  I BM  1800,  Technical  Report  11,  Concomp  Project, 
University  of  Michigan,  Ann  Arbor,  October  1968. 
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the  octal  integer  in  the  AC  and  system  variable  TRMCHR  con¬ 
taining  the  terminating  character.  Only  the  low-order  eighteen 
bits  of  any  number  are  kept.  Note  also  that  for  signed  quanti¬ 
ties  to  have  significance  the  magnitudes  of  the  numbers  must  be 
less  than  2 1 1  -  1 (  =  1 3 1 0 7 1  Q  =  377777g). 

Only  one  of  RDOCT  and  RDDEC  should  be  executing  at  the 
same  time  since  they  use  common  intermediate  routines. 

RDDEC 

Purpose:  To  read  and  translate  a  stream  of  ASCII  char¬ 

acters  into  a  decimal  number. 

Calling  Sequence:  RDDEC 

JMS  INPUT 

ERRET,  - 

NRMRET ,  - 

The  action  for  RDDEC  is  the  same  as  for  RDOCT  except  that 
all  numbers  are  decimal. 

Only  one  of  RDOCT  and  RDDEC  should  be  executing  at  the 
same  time  since  they  use  common  intermediate  routines. 

PROCT 

Purpose:  To  translate  the  contents  of  the  AC  into  a 

stream  of  six  octal  ASCII  characters,  unsigned. 

Calling  Sequence:  AC  =  Number 

PROCT 

JMS  OUTPUT 


RETURN, 


-44- 


OUTPUT  is  a  routine  which  will  accept  the  stream  of  ASCII 
characters  produced,  for  example,  TPRA.  The  number  is  treated 
as  unsigned.  Leading  zeros  in  the  output  stream  are  replaced 
by  the  contents  of  system  variable  LEDING.  LOCOSS  initialization 
sets  LEDING  to  260  octal,  an  ASCII  zero.  Thus  LEDING  =  240 
would  produce  leading  blanks,  and  LEDING  =  0  would  produce 
ASCII  NULLs  (which  are  ignored  by  the  teleprinter  routines). 

Only  one  of  PROCT  and  PRDEC  should  be  executing  at  the 
same  time  since  they  use  common  intermediate  routines. 

PRDEC 

Purpose:  To  translate  the  contents  of  the  AC  into  a 

stream  of  six  decimal  ASCII  characters,  unsigned. 

Calling  Sequence:  AC  =  Number 

PRDEC 

JMS  OUTPUT 

The  action  for  PRDEC  is  the  same  as  for  PROCT  except  that 
the  number  converted  is  decimal. 

Only  one  of  PROCT  and  PRDEC  should  be  executing  at  the  same 
time  since  they  use  common  intermediate  routines. 
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2.5  Input/Output 

2.5.1  Introduction 

LOCOSS  I/O  is  buffered  and  overlapped  as  much  as 
possible  and  is  done  under  interrupt  control,  i.e., 
asynchronously  with  the  user's  program.  Thus  when  the 
user  calls  an  output  routine  and  the  routine  returns,  the 
program  can  consider  the  operation  to  be  completed  and 
continue  with  something  else,  even  though  the  operation 
will  not  be  completed  for  some  time.  On  input,  the  tape 
reader  and  dataphone  are  overlapped  and  will  read  ahead 
if  the  user  is  slow  in  taking  information  from  the  buffers. 
Calling  the  keyboard  for  input  results  in  an  initial 
wait  until  an  entire  line  has  been  entered,  but  parallel 
lines  of  execution  can  be  executing  while  the  task  awaiting 

input  is  BUSY'ed.  The  only  devices  not  handled  under 

interrupt  control  are  the  character  generator  display 
routines  and  the  IBM  1800-PDP7  interface  routines  which 
handle  I/O  on  a  demand  basis  (Sections  2. 5. 2. 7  and  2. 5. 2. 8). 

Recall  that  on  input  operations  a  buffer  may  be 

empty  (i.e.,  no  input  is  available)  and  that  on  output,  the 

buffer  may  be  full.  Control  is  not  returned  to  the  user 
when  his  line  of  execution  encounters  one  of  these 
blocking  conditions  until  the  block  is  removed  and  the 
transfer  can  be  made.  For  example,  a  call  for  input  from 
the  high-speed  reader  will  not  return  until  the  reader 
has  been  started  and  a  character  read. 

Almost  all  I/O  routines  have  standard  calling  sequences. 
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Input  is  requested  by  merely  calling  the  associated  routine. 
Upon  return  the  AC  contains  the  input  item.  Where  meaning¬ 
ful,  there  may  be  alphanumeric  and  binary  reads  from  the 
same  device  (e.g.,  the  high-speed  reader).  Output  is 
performed  by  loading  the  AC  with  the  item  and  callin„  the 
desired  routine.  Upon  return,  the  operation  may  be  assumed 
to  be  completed.  Again,  there  may  be  binary  and  alphanumeric 
writes.  For  alphanumeric  write  commands,  either  one  or  two 
characters  may  be  passed  to  the  device  at  the  same  time.  To 
achieve  this,  the  low-order  16  bits  of  the  AC  are  considered 
as  two  eight-bit  bytes  with  the  high-order  byte  considered 
first.  If  the  high-order  eight  bits  are  zero,  they  are 
ignored  (not  passed  on  to  the  device).  The  low-order 
byte  is  always  passed  to  the  device,  regardless  of  its 
zeroness.  For  example,  the  following  sequences  produce 
identical  results: 


LAC 

(301) 

LAC  (140702) 

TPRA 

TPRA 

LAC 

(302) 

TPRA 

That  is,  they  both  result  in  the  letters  "AB"  being  typed. 
The  double  character  transfer  is  much  more  efficient  in 
terms  of  time. 

Note:  all  devices  using  ASCII  code  expect  DEC-style 

ASCII,  i.e.,  the  high-order  or  200  bit  is  always  set. 

Each  device  has  an  associated  initialization  routine 
which  restores  the  device  status  and  buffers  to  their  origi¬ 
nal  state  and  assigns  the  standard  system  routines  to  ser¬ 
vice  the  device.  All  initialization  routines  must  be  called 
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with  interrupts  off.  All  other  I/O  routines  may  be  called 
with  interrupts  off  or  on  but  always  return  with  interrupts 
on.  Exceptions  to  this  are  noted  in  the  routine  descriptions. 
If  the  user  wishes  to  handle  the  I/O  for  a  given  device 
himself,  he  may  do  so  by  first  calling  routine 
INTABL  with  appropriate  parameters.  INTABL  should  also  be 
called  if  any  display  interrupts  are  expected.  The  user 
is  expected  to  provide  a  routine  for  each  display  interrupt 
he  enables.  Since  the  keyboard  and  teleprinter  routines 
are  highly  interactive,  both  must  be  changed  if  one  is 
changed.  This  condition  also  applies  to  the  clock  and 
reader  routines. 

2.5.2  Device  Descriptions 

2. 5. 2.1  Paper  Tape  Punch 

The  paper  tape  punch  is  the  simplest  of  all  of  the  I/O 
devices  since  there  are  no  control  characters  or  special 
cases  to  worry  about.  The  only  special  circumstance  that 
can  arise  is  the  out-of-tape  condition,  and,  since  this 
cannot  be  sensed  from  the  PDP-7,  the  user  must  ensure  that 
there  is  enough  tape  in  the  feed  box  before  his  program 
starts  punching. 

Alphanumeric  and  binary  calls  to  the  punch  routines  may 
be  interspersed  from  the  user's  line  of  control  by  merely 
calling  the  associated  routines. 

System  variable  PCHLOC  contains  the  address  of  the 
system  buffer  control  block  for  the  punch.  By  changing 
the  BCB  the  knowledgeable  user  may  provide  a  different, 
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larger  buffer,  or  may  play  any  other  tricks  he  likes. 


PCHI 

Purpose:  To  initialize  the  de v i ce - hand  1 i ng  routine 

for  the  punch  to  be  the  standard  routine 
and  to  clear  the  punch  output  buffer. 
Calling  Sequence:  IOF 

PCHI 


RETURN, -  /IOF 


PCHA 

Purpose:  To  punch  the  one  or  two  ASCII  characters  in 

the  accumulator  in  alphanumeric  mode. 
Calling  Sequence:  AC  =  one  or  two  characters. 

PCHA 


RETURN, -  /ION 


PCHB 

Purpose:  To  punch  the  contents  of  the  accumulator  in 

binary  mode,  i.e.,  such  that  a  RDRB  call 
would  return  with  the  same  word. 

Calling  Sequence:  AC  =  18-bit  word. 

PCHB 

RETURN, -  /ION 

See  the  PDP- 7  User' s  Handbook  (pp.  76-77)  for  the  tape 


format  of  a  binary  word. 


I 
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2. 5. 2. 2  Paper  Tape  Reader 

The  high-speed  paper  tape  reader  on  the  PDP-7  is  some¬ 
what  unique  among  devices  of  this  sort  in  that  there  is 
no  way  to  sense  directly  the  physical  end  of  tape.  To 
remedy  this  situation,  the  reader  routines  recognize 
the  ASCII  XOFF  character  (023)  as  the  physical  end  of  tape 
and  will  halt  the  tape  reader  when  this  character  is  read. 

This  convention  eliminates  some  of  the  difficulties  en¬ 
countered  in  reading  spurious  characters  caused  by  the 
skewed  end  of  a  tape  and  thus  helps  to  protect  the  user. 

If,  however,  there  is  no  XOFF  near  the  end  of  the  tape,  the 
tape  will  run  out.  By  means  of  a  timer  arrangement  with  one 
of  the  simulated  clocks,  this  condition  will  be  recognized. 

When  it  is,  the  reader  routines  will  insert  an  XOFF  into 
the  buffer  for  the  user's  information  and  stop  the  reader. 
Stopping  the  reader  (i.e.,  clearing  the  reader  select)  thus 
allows  the  user  to  insert  a  new  tape  without  fear  of  the 
tape's  running  away  before  it  is  seated  properly.  The 
user  thai  indicates  that  the  new  tape  is  ready  by  the 
message  to  the  Command  Language  Interpreter:  "(ESC)HSR". 

Of  course,  the  character  (023)  may  be  legitimate  data 
and  not  a  device  control  character.  If  the  user  program  can 
detect  this  condition,  it  may  call  subroutine  RDRSEL  which 
restarts  the  reader.  A  user  sitting  at  the  keyboard  can 
also  detect  this  condition  and  restart  the  reader  via 
"(ESC)HSR."  Since  the  XOFF  is  transferred  to  the  user  program, 
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no  data  are  lost.  System  variable  RDR-LOC  contains  the  address 
of  the  system  buffer  control  block  for  the  reader. 


RPR  I 

Purpose:  To  initialize  the  d ev  i  ce- hand  1 i ng  for  the 

reader  to  be  the  standard  routine  and  to 
clear  the  current  contents  of  the  reader 
buffer . 

Calling  Sequence:  IOF 

RDR I 


RETURN, 


/IOF 


RDRA 

Purpose:  To  return  in  the  ’.ow-order  bits  of  the  AC 

the  next  eight-bit  alphanumeric  character 
from  the  reader  buffer. 

Calling  Sequence:  RDRA 

RETURN , -  /AC  =  8-bit  character;  ION 

RURB 

Purpose:  To  return  in  the  AC  the  next  binary  word 

from  the  reader  buffer. 

Calling  Sequence:  RDRB 

RETURN, -  /ION 


See  the  PUP- 7  User1 s  Handbook  ( p p .  76-77)  for  the  tape 
format  of  a  binary  word.  The  end-of-tape  character  (023) 
will  cause  the  reader  to  stop  in  binary  mode  also. 
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RDRSEL 

Purpose:  To  start  the  high-speed  paper  tape  reader. 

Calling  Sequence:  IOF 

RDRSEL 

RETURN, -  /with  IOF 

RDRSEL  issues  the  actual  hardware  select  instructions 
to  set  the  reader  in  motion  and  sets  a  timer  so  that  if 
there  is  no  tape  in  the  reader,  the  device  routines  can 
insert  an  XOFF  into  the  buffer  and  clear  the  select.  The 
CLI  command  "HSR"  calls  RDRSEL.  The  user  should  not  call 
RDRSEL  from  either  his  program  or  the  CLI  unless  the  reader 
has  not  been  started  since  the  beginning  of  a  program  or  an 
XOFF  has  been  encountered  (either  on  the  tape  or  as  the 
result  of  a  time-out). 

2. 5. 2. 3  Teleprinter 

The  teleprinter  and  associated  routines  provide  a 
character-oriented  output  device  with  some  formatting. 

The  system  variable  "TABCNT,"  accessed  directly  in  the 
system  communication  area,  defines  equi-sized  tab  stops 
on  the  teleprinter.  Since  the  KSR-33  does  not  have  a 
real  tab  mechanism,  the  tabs  are  simulated  from  the  output 
routines  by  outputting  the  appropriate  number  of  spaces 
to  position  the  carriage  at  the  next  "stop."  TABCNT 
is  defined  on  the  LOCOSS  symbol  definition  tape  and  may 
be  accessed  directly  by  the  user.  For  example, 
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LAC  (12)  /Octal  Radix 

DAC  TABCNT 

will  effect  "stops"  at  carriage  positions  10,  20,  30 ,  • • • 
(decimal).  A  value  of  zero  will  be  defaulted  to  a  value  of 
one.  TABCNT  may  also  be  set  by  the  CLI  command  TAB 
(see  2.3  Command  Language  Interpreter).  Other  editing  of 
the  output  stream  is  given  below. 

Since  the  teleprinter  is  a  common  output  device  for 
program  communication,  the  situation  often  arises  that 
two  tasks  may  wish  to  print  a  message  at  the  same  time. 

Since  the  output  routines  are  character-oriented  and  may 
be  called  directly  by  any  task,  the  result  may  be  unin¬ 
telligible  interleaving  of  character  information  from  the 
two  tasks.  To  avoid  this  difficulty,  the  user  may  write 
his  programs  to  employ  the  programming  convention  of 
"seizing"  the  use  of  the  teleprinter  at  the  beginning  of  a 
print  line,  and  "releasing"  it  at  the  last  character  of 
the  line,  the  carriage  return.  Then,  during  the  period 
that  the  teleprinter  is  being  used  by  one  task  (i.e., 
while  it  is  "seized"),  another  task  may  not  seize  it,  so  that 
a  whole  line  is  printed  without  interference.  After  the 
teleprinter  has  been  released,  any  task  may  then  seize 
it  and  print  its  line  of  information. 
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This  convention  is  implemented  in  LOCOSS  by  means  of 
the  system  routine  SEZTPR.  Thus,  whenever  a  user  wishes  to 
start  a  teleprinter  line,  he  calls  SEZTPR  as  a  subtask. 

Upon  return  from  SEZTPR,  the  user  may  print  the  line  with¬ 
out  fear  of  interference;  tnat  is,  he  may  make  successive 
calls  on  TPRA  until  he  prints  a  carriage  return. 

Calling  TPRA  with  a  carriage  return  as  the  low-order  byte 
in  the  AC  automatically  releases  the  teleprinter  so  that 
another  task  may  seize  it. 

Of  course,  if  a  user  does  not  expect  to  be  printing 
from  independent  tasks  he  need  not  bother  calling  SEZTPR 
at  the  beginning  of  a  line,  since  no  other  task  will  have 
seized  the  teleprinter  and  be  in  the  process  of  printing. 

TPRI 

Purpose:  To  initialize  the  device-handling  routine 
for  the  teleprinter  to  be  standard  routine, 
to  clear  the  contents  of  all  print  buffers, 
and  to  release  the  teleprinter  if  it  has 
been  seized. 

Calling  Sequence:  10F 

TPRI 

RETURN, -  /  IOF 

TPRA 

Purpose:  To  print  the  one  or  two  ASCII  characters  in 


the  AC. 


Calling  Sequence:  AC  ■  One  or  two  ASCII  characters. 

TPRA 

RETURN, -  /ION 

The  following  translations  of  the  ASCII  character  set 
are  made  in  the  stream  of  output  characters: 

1)  Carriage  return  (21S)  is  mapped  into  a  carriage 
return  and  line  feed  (212).  (Note  that  ( 0 1 S )  is 
typed  alone  as  only  a  carriage  return.) 

2)  Line  feed  (212)  is  not  printed.  (Note,  however, 
that  (012)  will  print  as  a  line  feed.) 

3)  Zero  characters  are  not  printed,  i.e.,  they  are 
ignored. 

4)  The  tab  character  (211)  generates  enough  spaces 
to  move  the  carriage  to  the  next  tab  stop,  i.e., 
next  multiple  of  TABCNT. 

A  carriage  return  in  the  low-order  byte  of  the  accumula¬ 
tor  will  "release"  the  teleprinter  (see  SEZTPR). 

SEZTPR 

Purpose:  To  seize  the  use  of  the  teleprinter  routines 
for  the  duration  of  a  print  line. 

Calling  Sequence:  SUBTSK  /IOF  or  ION 

SEZTPR 

RETURN, -  /ION,  with  AC 

restored 


*> 
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If  the  teleprinte.*  routines  have  been  seized  and  not 
released  by  another  task,  control  will  not  be  returned 
to  the  calling  task  until  the  release  is  given.  Thus  when 
control  is  transferred  to  location  RETURN,  the  teleprinter 
routines  may  be  called  without  fear  of  interference.  The 
accumulator  is  saved  and  restored  around  the  call  to  SEZTPR. 

A  call  to  TRPA  with  a  carriage  return  in  the  low-order 
byte  of  the  accumulator  will  release  the  teleprinter.  If 
a".y  task  expects  to  use  the  seize-release  convention,  all 
tasks  using  the  teleprinter  should  do  so. 

2. 5. 2. 4  Keyboard 

The  teletype  keyboard  is  treated  as  a  line-oriented 
input  device.  That  is,  a  call  for  input  is  essentially 
a  call  for  the  input  of  an  entire  line  —  a  string  of  charac¬ 
ters  ended  by  a  carriage  return.  The  keyboard  routines 
will  collect  the  line  and,  upon  rc  eipt  of  a  carriage  return, 
will  feed  characters  one  at  a  time  to  the  user  via 
successive  calls  on  KBDA .  During  collection  of  the  line, 
and  at  any  time  until  the  input  of  a  carriage  return, 
the  line  may  be  altered  by  the  two  editing  characters, 
LEFTARROW  («-)  and  RUBOUT.  LEFTARRON  causes  the  last- 
typed  character  to  be  deleted  from  the  line  image. 

Two  LEFTARROWs  delete  the  last  two  characters,  etc. 
Backspacing  beyond  the  first  character  in  a  line  has  no 
effect.  The  ESC  character  (control-shift-K)  cannot  be 
deleted  by  LEFTARROW.  Typing  the  RUBOUT  character  causes 


deletion  of  the  whole  line,  at  which  time  a  pound  sign 
(ff)  and  a  carriage  return  are  then  printed  by  the  key¬ 
board  routines  so  that  input  starts  on  a  new  line.  (The 
output  of  and  other  system-control  characters  depends 
on  the  current  state  of  the  echo  condition.  (See  ECHO 
below. ) 

If.  when  a  carriage  return  is  entered,  the  first 
character  in  the  edited  line  is  ESC,  the  line  is  sent 
to  the  CLI.  When  the  CL1  is  finished,  the  keyboard 
is  again  available  for  input  (see  2.3  Commar.J  Language 
Interpreter) . 

If,  at  any  time,  the  input  buffer  is  full  when  a 
character  is  typed,  a  LEFTARROW  and  RETURN  will  be  typed 
back  at  the  user  indicating  that  the  last-typed  character 
did  not  enter  the  buffer  (see  ECHO).  The  user  must 
then  delete  at  least  one  more  character  so  that  he  may 
enter  a  carriage  return  to  end  the  line.  The  input  buffer 
has  room  for  seventy-two  characters;  that  is,  seventy-one 
characters  plus  carriage  return. 

When  no  read  is  outstanding  on  the  keyboard  (i.e., 
when  KBDA  has  not  been  called,  or  when  a  line  has  been 
entered  and  not  entirely  read  from  the  buffer  by  repeated 
calls  on  KBDA)  the  only  input  allowed  is  a  command  line 
(i.e.,  a  line  begun  with  ESC).  Any  other  input  is  ignored. 
In  fact,  a  "# (RETURN)"  is  immediately  typed  back  at  the 
user  if  he  tries  to  type  anything  else  (see  ECHO). 
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So  that  a  user  sitting  at  the  teletype  may  know  when 
a  program  is  expecting  input,  the  program  may  choose  the 
option  of  supplying  a  prompting  character  (question  mark-7) 
when  a  new  line  is  expected.  This  choice  is  given  in  the 
system  variable  PRMPTC.  When  PRMPTC  is  zero,  the  prompting 
character  is  given.  When  PRMPTC  is  nonzero,  the  prompt 
is  not  given.  PRMPTC  is  defined  in  the  LOCOSS  symbols 
and  may  be  accessed  directly  by  the  user.  For  example, 

CLC 

DAC  PRMPTC 

will  turn  prompting  off.  Deletion  of  the  input  line  by 
RUBOUT  or  intervening  CLI  commands  will  cause  the  prompting 
character  to  be  re-issued  at  the  beginning  of  the  next 
line.  System  reinitialization  sets  prompting  on. 

If  a  user  starts  an  input  line  while  a  program  is 
printing,  the  printing  will  be  halted  until  the  input  line 
has  been  finished  by  either  a  carriage  return  or  RUBOUT. 

ECHO 

The  teletype  on  the  PDP-7  can  operate  in  either  half- 
or  full-duplex  mode  by  means  of  a  throw  switch  on  the 
PDP-7.  Half-duplex  operation  means  that  hardware  in  the 
teletype  controller  will  automatically  print  any  character 
that  is  struck  on  the  keyboard.  Full-duplex  means  that 
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printing  is  completely  independent  of  keyboard  operations. 
Normal  operation  under  LOCOSS  expects  the  switch  to  be  in 
the  full-duplex  position. 

The  two  modes  of  operation  for  control  of  the  keyboard 
are  designated  as  "echo-on"  and  "echo-off."  Which  of  these 
two  modes  the  keyboard  routines  should  assume  is  determined 
by  the  state  of  the  system  variable  ECHOSW.  When  ECHOSW 
is  zero,  the  mode  is  echo-unj  when  ECHOSW  is  nonzero,  the 
mode  is  echo-off.  For  example,  "DZM  ECHOSW"  will  change 
the  mode  to  echo-on.  The  mode  may  also  be  changed  by  the 
ECN  (echo-on)  and  ECF  (echo-off)  commands  to  the  CLI. 

System  reinitialization  sets  echo-on. 

When  the  system  is  in  echo-on  state,  the  keyboard 
routines  will  print  back  at  the  user  any  character 
struck  on  the  keyboard  and  additional  control  characters 
to  help  format  the  input  and  thus  make  it  more  readable. 
Specifically,  when  in  echo-on  mode  the  keyboard  routines 
will: 

1)  Print  any  character  struck  on  the  keyboard; 

2)  Supply  a  line  feed  after  every  carriage  return 
typed  by  the  user; 

3)  Supply  a  suitable  number  of  spaces  to  position  the 
carriage  at  the  next  tab  stop  when  a  TAB  is  typed 
by  the  user  (see  2. 5. 2. 3  Teleprinter,  variable 
TABCNT) ; 
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4)  Print  an  "AT"  sign  (•)  when  an  ESC  character 
(control-shift-k)  is  typed  by  the  user;  and 

5)  Supply  a  LEFTARROW  and  carriage  return  on  buffer 
overflow,  and  a  pound  sign  and  carriage  return 
on  RUBOUT  or  unsolicited  input. 

The  echoed  characters  are  kept  in  a  separate  print 
buffer.  If  this  buffer  overflows,  no  characters  which  are 

struck  will  be  printed  or  entered  into  the  keyboard  buffer 

« 

until  the  echo  buffer  is  emptied.  In  any  case,  the 
printed  line  will  be  a  faithful  reflection  of  the  contents 
of  the  keyboard  buffer. 

In  echo-off  mode  the  system  will  not  print  the  charac¬ 
ter  struck  nor  will  it  supply  any  of  the  control  characters 
described  above.  Thus,  "echo-off"  means  that  nothing 
will  appear  on  the  teleprinter  except  what  is  specifically 
printed  by  the  user's  program  or  the  Command  Language 
Interpreter. 

Echo-off  mode  is  usually  used  in  conjunction  with  the 
337  display,  so  that  the  input  line  is  displayed  on  the 
screen  rather  than  on  the  teleprinter.  T~  assist  this 
process,  the  system  keyboard  input  buffer  is  kept  in 
a  state  suitable  to  be  used  as  a  337  display  file  of  the 
currently  edited  input  line.  This  display  file  assumes 
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it  will  be  entered  via  a  PJMP  and  that  the  character 
generator  is  In  the  seven-bit  mode.  The  structure  of 
this  file  is: 


KBDBUF, 


EDSiCHR 


/edited  line 


0 

1 


/unused  part  of  buffer 
/are  null  characters 

/escape  character 


EDSISVEC 
4045  /put  up  the  cursor 
POP 


The  system  variable  KBDLOC  contains  the  address  of  the  buffer 
control  block  for  the  system  input  buffer.  (See  2.6 
Buffer  Management  Routines  for  the  structure  of  the 
buffer  control  block.)  So,  in  order  to  insert  the  editing 
line  into  a  display  file,  the  following  coding  is  sufficient: 


LAC 

I  KBDLOC 

/pick  up  the 

keyboard  buffer. . . 

/ . . . location, 

i.e.,  KBDBUF 

DAC 

EDILIN 

/store  it  in 

the  display  file 

where  EDILIN  is  the  second  word  of  a  PJMP  instruction  in 
the  user's  display  file.  The  user- supp 1 i ed  character 
generator  table  is  assumed  to  dispatch  on  the  ASCII 
character  set,  with  zero  a  null  character  and  ore  (1) 
the  generator  escape  character  (see  Section  2. 5. 2. 7  for 
a  use  of  this  facility). 
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KBDI 

Purpose:  To  Initialize  the  device-handling  routine 

for  the  keyboard  to  be  the  standard  routine, 
clear  all  input  buffers,  and  reinitialize 
the  Command  Language  Interpreter. 

Calling  Sequence:  IOF 

KBUI 

RETURN,  -  /IOF 


KBDA 

Purpose:  To  return  in  the  low-order  bits  of  the  ac- 

% 

cumulator  the  next  eight-bit  character  from 
the  input  buffer,  and  also  to  cause  the 
prompting  character  to  be  given  if  prompt¬ 
ing  is  on  and  the  buffer  is  empty. 

Calling  Sequence:  KBDA 

RETURN,  -  /ION 

See  the  discussion  under  KEYBOARD  for  the  effect  of 
system  variables  ECHOSW  and  PRMPTC,  and  input  editing. 

2.5.2.S  IBM  1800  Logical  Disk  Files* 

The  logical  file  system  for  the  IBM  1800  is  available 

to  the  PDP-7  across  the  1800-7  interface  when  the  appropriate 

interrupt  service  subroutine  has  been  initialized  in  1800 

*  Brender,  R.F.,  Frantz,  D.R.,  Foy,  J.L.  Jr.,  and  Schunior, 

T . W. ,  Specialized  System  Software  for  Interacting  DEC 
PDP-7  and  IBM  DTPO,  Technical  Report  11,  Concomp  Project, 
University  of  Michigan ,  Ann  Arbor,  October  1968. 
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memory.  Details  on  the  file  routines  are  available  in 
another  aemo,  but  the  features  available  to  the  PDP-7  are 
briefly  discussed  below.  In  general,  the  user  can  treat 
a  disk  file  as  a  serial  source  and  sink  for  characters. 

He  can  create,  open,  write  into  or  read  from,  close,  and 
destroy  files. 

To  write  a  file,  the  user  must  first  create  the  file 
(if  it  does  not  already  exist),  open  it  for  output,  write 
into  it,  and  finally  close  it.  To  read  the  file,  he  must 
open  it  for  input,  read  from  it,  and  close  it.  By  conven 
tion,  symbolic  files  reside  on  the  disk  in  EBCDIC  and  are 
translated  to  and  from  ASCII  on  reads  and  writes  by  the 
IBM  1800  interrupt  service  subroutine. 

With  regard  to  the  file  routines,  the  interaction 
between  the  two  machines  is  master  (PDP-7)  to  slave  (IBM 
1800).  The  PDP-7  tells  the  1800  when  it  wants  something 
done,  the  1800  tries  to  do  it,  and  then  tells  the  PDP-7 
whether  the  request  was  successful.  Thus,  every  transfer 
and  command  is  acknowledged.  If  tha  function  requested 
cannot  be  carried  out  (e.g.,  the  file  to  be  opened  does 
not  exist  or  there  is  an  end-of-file  on  a  read),  an  error 
indication  is  returned  to  the  PDP-7  and  the  LOCOSS  disk 
routines  will  transfer  to  a  user  error  routine.  The  disk 
routines  operate  with  interrupts  on  or  off  and  do  not 
change  the  interrupts-enabled  status. 
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DSKGET 

Purpose:  To  get  an  eight-bit  character  fro*  the 
currently  opened  input  file. 

Calling  Sequence:  DSKGET 
RETURN,  - 

The  character  returned  will  be  translated  from  EBCDIC 
to  ASCII  depending  on  the  manner  in  which  the  file  was 
opened.  (See  below.)  If  no  file  is  open,  or  if  translation 
to  ASCII  was  requested  and  is  not  possible,  or  if  the  end 
of  the  file  has  been  reached,  the  1800  will  give  an  error 
indication  and  control  will  pass  to  the  current  error  rou¬ 
tine  . 

DSKPUT 

Purpose:  To  put  the  one  or  two  eight-bit  characters 

in  the  accumulator  into  the  currently 
opened  output  file. 

Calling  Sequence:  AC  *  1  or  2  characters 

DSKPUT 
RETURN,  - 

The  characters  will  be  translated  from  ASCII  to  EBCDIC 
or  not  depending  on  the  way  the  output  file  was  opened. 

(See  below.)  If  no  file  is  open  or  if  translation  to 
EBCDIC  was  requested  and  is  not  possible,  or  if  there  is 
no  more  room  on  the  disk  for  files,  the  1800  will  give  an 
error  indication  and  control  will  pass  to  the  current  error 


routine . 
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DISK 

Purpose:  General  purpose  commuiication  with  the  IBM 

1800  service  routine. 

Calling  Sequence:  AC  ■  8-bit  character  or  file  number 

(if  applicable) 

DISK 

Disk  op  code 

RETURN,  -  AC  «=  character  (if  applicable) 

The  disk  op  codes  are  given  below  in  symbolic  form  as 
they  are  defined  on  the  LOCOSS  symbol  tape.  They  represent 
functions  which  the  IBM  1800  interrupt  service  routine  will 
perform.  This  list  may  be  extended.  Only  the  low-order 
eight  bits  of  the  accumulator  are  used.  If  any  error  occurs, 
control  will  be  passed  to  the  current  error  routine.  A 
typical  call  would  be: 

LAW  15 

DISK  /open  file  15  for  input,  translated. 

D . OP  IT 

RETURN, - 


SYDSK 

Purpose:  General  purpose  communication  with  the  IBM 

1800  service  routine  with  an  immediate 
error  return. 

Calling  Sequence:  AC  *  eight-bit  character  or  file 


number  (if  applicable) 


SYSDSK 


Disk  op  Code 

ERRET,  AC  ■  error  number 

NRMRET,  AC  »  character  (if  applicable) 

S.SDSK  is  identical  to  DISK  except  that  if  an  error 
occurs,  control  will  be  transferred  to  location  ERRET  in¬ 
stead  of  the  error  routine  set  up  through  DSKERR.  If  no 
error  occurs  control  is  transferred  to  location  NRMRET. 
DSKERR ' s  error  exit  is  not  disturbed  by  a  SYSDSK  call. 

DSKERR 

Purpose:  To  set  the  disk  error  return  to  a  user 

program . 

Calling  Sequence:  DSKERR 

ERROR  INSTRUCTION 
RETURN,  - 

The  error  instruction  will  typically  be  a  JMS  or  JMP 
to  the  user's  program.  The  last  such  error  routine  set  up 
by  calling  DSKERR  will  be  executed  by  the  LOCOSS  disk  error 
handler  if  a  disk  error  occurs  in  subroutines  DSKGET, 

DSKPUT ,  DISK,  ICYRED,  or  ICYWRI .  Upon  entry  to  the  user's 
error  routine,  the  accumulator  will  contain  the  error  number 
(see  below)  and  location  20  (octal)  will  contain  the  service 
request  as  presented  to  the  1800;  i.e.,  bits  2-9  contain 
the  operation  code  and  bits  10-17  contain  the  argument. 
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If  the  user's  error  routine  was  entered  by  a  JMS  and  it 
does  a  normal  subroutine  exit  to  the  LOCOSS  disk  error 
handler,  the  entire  accumulator  will  be  returned  to  the 
user  disk  call  which  caused  the  fault,  as  if  nothing  had 
intervened.  The  default  handling  for  a  disk  error  (restored 
by  RESET  and  in  effect  until  the  user  calls  DSKERR)  is  to 
print  an  error  message  (error  number  3)  and  DELETE  the  cur¬ 
rent  line  of  execution. 

The  error  codes  are  below  (in  octal) .  Some  of  these 
error  codes  may  also  appear  if  the  1800  file  routines  are 
snarked,  but  in  that  case  it's  all  over  anyway. 
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QP  CODE 
D.ECHO 

D.ECOA 

D.ECOB 

D.CRE 

D.DES 

D.OPOU 

D.OPOT 


D.  PUT 

D.CLO 
D.OPIU 
D . OP  IT 


D .  GET 


D.CLI 


Table  2.  Disk  Operation  Codes 
FUNCTION 

Return  the  character  in  the  AC.  (Used  mainly  for 
determining  that  the  1800  is  awake.) 

Return  the  ASCII  equivalent  of  the  EBCDIC  character 
in  the  call. 

Return  the  EBCDIC  equivalent  of  the  ASCII  character 
in  the  call. 

Create  a  file  with  the  number  given  in  the  call. 
Destroy  the  file  with  the  number  given  in  the  call. 
Open  the  given  file  for  untranslated  output. 

Open  the  given  file  for  translated  output  (i.e., 
translate  all  characters  to  EBCDIC  before  storing 
on  the  disk)  .  » 

Put  the  character  in  the  AC  into  the  currently 
opened  output  file. 

Close  the  output  file. 

Open  the  given  file  for  untranslated  input. 

Open  the  given  file  for  translated  input  (i.e.f 
translate  the  EBCDIC  characters  to  ASCII  before 
returning) . 

Get  a  character  from  the  currently  opened  input 
file. 

Close  the  input  file. 


Table  2  cont'd 


OP  COLE  FUNCTION 

D.CLR  Close  any  files  that  are  opened  (cannot  fail). 

R.REDT  Get  a  character  from  the  IBM  1800  copy  task 

translated. 

D.WRIT  Give  a  character  to  the  IBM  1800  copy  task 
translated 

D.REDU  Get  a  character  from  the  IBM  1800  copy  task 
untranslated. 

D.WRIU  Give  a  character  to  the  IBM  1800  copy  task 


untranslated. 


A 


\ 
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CODE  (octal J 

1 

2 

3 

4 

5 

6 
7 

10 

11 

12 


13 


14 


Table  3.  Disk  Error  Codes 
MEANING 
Invalid  command. 

"Open"  request  rejected — no  such  file. 
"Open"  request  rejected — file  already 
in  use  by  another  program  at  the  moment. 
"Put"  error — file  not  open. 

File  overflow  —  no  more  room  on  disk 
for  "Put." 

"Get"  error— file  not  open. 

"Close"  error — file  not  open. 

"Create"  error — file  already  exists  or 
number  not  in  legal  limits. 

"Create"  error— no  more  room  on  the  disk. 
"Destroy"  error — no  such  file  exists, 
or  the  file  is  open.  It  must  be 
closed  before  being  destroyed. 

Translation  to  ASCII  not  possible  on 
read  from  file  or  translate  command. 
Translation  to  EBCDIC  not  possible. 

If  encountered  on  a  "Put,"  a  percent 
sign  (%)  is  inserted  in  the  file. 


Table  3.  cont'd 


CODE  (octal) 
15 


16 


357 


374 

375 

376 

377 


MEANING 

Copy  port  on  IBM  1800  (ICY)  busy. 

Try  again  later. 

Illegal  use  of  bootstrap  command  (on  a 
file  numbered  more  than  12  octal). 
End-of-file  read  on  a  "Get,"  i.e., 
the  last  character  has  already  been 
read.  The  file  is  closed  after  this 
error  code  is  returned. 

The  1800  copy  port  was  quiescent  on  a 
WRITE. 

The  1800  copy  port  was  quiescent  on  a 
READ. 

The  1800  didn't  take  the  service  request. 
The  1800  took  the  service  request  but 
didn't  come  back  with  an  answer. 
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2. 5. 2. 6  IBM  1800  Copy  Port 

Another  feature  of  the  PDP7-IBM  1800  interface  routines 
is  a  logical  connection  to  the  copy  port  of  the  IBM  1800. 
Thus  the  user  may  use  other  1800  peripherals  than  the  disk 
in  moving  data  to  or  from  the  PDP7  by  issuing  to  the  IBM 
utility  program  the  proper  copy  to  or  from  "PDP-7." 

Running  programs  in  the  1800  also  have  access  to  this  port. 

PDP-7  access  to  this  facility  is  available  through  the 
"DISK"  subroutine  with  operation  code  parameters  D.REDT 
and  D.WRIT  for  translated  transfers  (i.e.,  symbolic  in¬ 
formation)  and  D.REDU  and  D.WRIU  for  untranslated  infor¬ 
mation  (i.e.,  binary  characters).  There  is,  however,  a 
special  error  code  (octal  15)  related  to  these  commands 
which  indicates  that  the  1800  copy  program  is  not  ready 

i 

to  service  the  call;  e.g.  data  from  previous  D. WRITs 
is  still  being  copied  to  the  typewriter,  or  the  card  reader 
hasn't  finished  reading  a  card  in  response  to  a  "D.REDT." 
This  "not  ready"  response  indicates  only  a  temporary 
blocking  condition  and  that  the  same  command  may  meet  with 
success  if  attempted  later.  The  four  ICY  (I_BM  £op^) 
routines  provided  recognize  this  "not  ready"  condition  and 
try  again  after  a  decent  interval.  (The  interval  is  to 
allow  the  1800  to  exit  from  its  interrupt  servicing  status 
and  do  the  other  I/O  work  required.) 


If  the  1800  returns  "not  ready,"  these  routines  will 
take  BUSY  exits,  allowing  other  task  processing  to  continue. 
Upon  return  from  BUSY,  the  operation  will  be  retried  unless 
a  given  time  (about  fifteen  seconds)  has  passed  since 
the  first  try.  If  fifteen  seconds  have  not  passed,  another 
BUSY  exit  will  be  taken  and  the  whole  process  repeated. 

If  the  time  is  up,  it  will  be  assumed  that  the  1800  really 
isn't  trying  very  hard,  and  control  will  be  passed  to  the 
current  disk  error  routine  with  an  error  number  of  374 
(octal)  for  WRITE  and  375  for  READ.  Any  other  errors  will 
also  cause  control  to  be  transferred  to  the  current  disk 
error  routine. 

ICYRDT 

Purpose:  To  read  an  eight-bit  ASCII  chracter  from  the 

IBM  1800  copy  port. 

Calling  Sequence:  ICYRDT  /IOF  or  ION 

RETURN, -  /ION 

If  EBCDIC  to  ASCII  translation  of  the  character  is  not 
possible  or  if  the  1800  copy  port  appears  to  be  quiescent, 
i.e.,  never  comes  ready,  control  will  be  passed  to  the  current 
disk  error  routine.  (See  DSKERR.) 


ICYWRT 


Purpose:  To  write  the  one  or  two  eight-bit  ASCII 
characters  in  the  accumulator  to  the 
IBM  1800  copy  port. 

Calling  Sequence:  AC  ■  one  or  two  characters  /ION  or  IOF 

ICYWRT 

RETURN, -  /ION 


If  ASCII  to  EBCDIC  translation  of  one  of  the  characters 
is  not  possible  or  if  the  1800  copy  port  appears  to  be 
quiescent,  i.e.,  never  comes  ready,  control  will  be  passed 
to  the  current  disk  error  routine.  (See  DSKERR.) 

ICYRDU 

Purpose:  To  read  an  eight-bit  binary  character  from  the 
IBM  1800  copy  port. 

Calling  Sequence:  ICYRDU  /I0T  or  ION 

RETURN, -  /ION 

If  the  1800  copy  port  appears  to  be  quiescent,  control 
will  be  passed  to  the  current  disk  error  routine. 


ICYWRU 

Purpose:  To  write  the  one  or  two  eight-bit  binary 

characters  in  the  accumulator  to  the  IBM  1800 
copy  port. 

Calling  Sequence:  AC  ■  one  or  two  characters  /ION  or  IOF 


ICYWRU 


RETURN, - 

If  thr  1800  copy  port  appears  to  be  quiescent,  control 
will  be  passed  to  the  current  disk  error  routine.  Recall  that 
if  the  high-order  byte  in  a  two- character  transfer  is  zero,  it 
will  be  ignored. 

2. 5. 2. 7  Character  Generator  Package 

The  character  generator  package  allows  the  user  to  dis¬ 
play  character  data  on  the  face  of  the  screen  by  treating 
the  display  as  sink  for  ASCII  characters  in  a  format 
compatible  with  other  ASCI  I -oriented  devices. 

The  package  is  available  as  a  set  of  routines  to  be 
loaled  from  the  I  EM  2310  disk  (see  system  routine  LOAD 
and  the  system  file  directory)  or  from  the  tape  labeled 
"HIGH  CORE  CHARACTER  ROUTINES."  Since  there  are  no 
relocation  and  program  linkage  facilities  in  the  current 
system,  the  package  is  lorded  into  a  predes ignate  1  area: 
16000-17577  octal.  The  dispatch  table  and  display  file 
for  the  characters  occupy  (approximately)  locations  16000- 
17000,  and  the  f i le- hand  1 i ng  routines  occupy  about  17000- 
17440;  locations  17440-17577  are  used  as  a  default  file 
location. 

The  file-handling  routines  and  their  parameters  are 
available  to  the  user  through  a  local  transfer  vector  at 
location  17000.  In  general,  for  the  case  of  default 
parameters,  entry  DISPLA  will  accept  one  or  two  ASCII 
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X 


characters  (in  normal  I/O  format)  and  add  them  to  the  file. 
If  more  than  seventy-two  (decimal)  characters  are  put  on 
a  line,  a  hyphen  and  a  carriage  return-line  feed  sequence 
is  automatically  inserted  after  the  seventy- second , 
starting  a  new  line.  A  maximum  of  forty  lines  is  dis¬ 
played,  and  the  character  file  buffer  is  circular  so  that 
only  the  last  forty  lines  generated  are  on  the  screen, 
with  the  oldest  line  being  deleted  from  the  top  as  new 
ones  are  added  on  the  bottom. 

The  package's  display  file  also  provides  an  echo  line 
on  the  display  face  for  input  from  the  keyboard.  A  cursor 
appears  at  the  bottom  of  the  screen  to  indicate  the  entry 
point  for  the  next  character  to  be  typed.  This  echo  line  is 
a  faithful  reproduction  of  the  input  line  being  collected 
by  LOCOSS,  reflecting  all  editing.  No  more  than  seventy- 
two  characters  will  be  accepted  before  a  carriage  return; 
and  if  LOCOSS  is  not  expecting,  or  will  not  allow,  input, 
nothing  will  appear  on  the  echo  line  even  if  something  is 
typed  (see  2. 5. 2. 4  Keyboard).  The  echo  line  is  quite 
useful  in  conjunction  with  keyboard  echo-off  mode.  There 
is  also  a  facility  for  the  user  to  insert  a  push-jump  into 
the  display  regeneration  loop  so  that  he  may  display 
other  than  character  information  on  the  face  of  the  screen. 

If  the  user  wants  to  use  only  the  characters  and  not  the 
file  routines,  he  may  load  the  package  and  then  use  the  file 


-76- 


routinc  area  (17000-17577)  for  his  own  uses.  Then,  in 
his  display  initialization  sequence,  he  should  include  the 
following  to  initialize  the  character  generator: 


LAW  216  /seven-bit  mode,  base  of 

/dispatch 
/table  at  16000 

SCG 


After  this,  to  display  characters  the  user  merely  includes 
the  enter  data-state  instruction  and  escape  character 
around  an  ASCII  list;  for  example  to  display  "AB"  : 


EDS  1CI1ARR 

301 

302 

ESCCIIR 


/  =  1 1  5 1 
/  =  ASC 1 1  "A" 

/=ASCII  "B" 
/escape  character. 


(See  below  for  control  character  definitions.) 


Character  File.  The  display  file  created  by  the 
package  is  highly  parameterized.  The  following  is  a 
summary  of  the  location  in  the  transfer  vector  which  will 
be  referred  to  symbolically  in  the  discussion  below. 

All  numbers  are  octal  unless  otherwise  specified. 
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NAME 

LOCATION 

DEFAULT 

DESCRIPTION 

INDISP 

17000 

Entry  to  initialize  display 
and  file. 

STOPDY 

17002 

Entry  to  stop  display. 

RESTRT 

17004 

Entry  to  restart  display. 

DISPLA 

17006 

Entry  to  add  characters 
to  file. 

DSP  BUF 

17010 

17454 

Beginning  of  character 
buffer . 

BUFSIZ 

17011 

123 

Size  of  buffer. 

PDLIST 

17012 

4370 

Location  of  push-down  list. 

JMPLOC 

17013 

Location  for  a  PJMP  to 
the  user's  file. 

YLOC 

17014 

1760 

Vertical  position  on  screen 
for  display  file. 

LINES 

17015 

-50 

-Maximum  number  of  lines 
to  be  displayed. 

CHARLIN 

17016 

-111 

-Maximum  ruifoer  of  characters 
or  a  line. 

PBUSEF 

17017 

0 

Push-button  use  flag. 

SICLOC 

17020 

4 

Initial  conditions  for  the 
displ ay . 
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Characters .  The  complete  set  of  ASCII  characters  is 
programmed  for  the  character  generator  with  a  dispatch 
table  operating  in  the  seven-bit  mode.  This  set  includes 
all  printing  graphics  and  the  following  special  cases 
for  non-printing  combinations. 


OCTAL 

ASCII 

EFFECT 

000 

NULL 

Does  nothing 

001 

SOH 

Escape  from  character  mode. 

004 

EOT 

Down  arrow  (J).  (For  editor  usage 

005 

WRU 

Diamond  (O).  (For  editor  usage.) 

Oil 

TAB 

Eight  spaces  . 

012 

LF 

Line  feed.  Decrease  y-coordinate 
by  12  (decimal ) . 

014 

FORM  FEED 

Null.  (For  editor  usage.) 

015 

CR 

Carriage  Return.  Set  x-coordinate 
to  zero 

021 

ETB 

Null.  (For  MTS  use  in  ending  a 
prompt  line.) 

023 

XOFF 

Null.  (For  editor  usage.) 

033 

ESC 

Displayed  as  (LOCOSS  Command 

Character. ) 

161 

One  space . 

162 

Two  spaces  . 

177  15  spaces.  (161  to  177  are  for  TAB 

spacing). 

The  remaining  nonprinting  characters  are  displayed  as  a 
single  space. 

These  characters  are  displayed  in  a  7  x  7  raster- 
point  matrix  with  the  graphic  itself  on  a  5  x  7  matrix. 
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* 

» 

* 

j 

* 

k 

Beam  Position  * 

Before  —  - x  *  x  x 


Character  Matrix 
♦ - » 

I 


Beam  Position 
x  x  (x  <  .  _  After 


Readable,  solid  characters  (1/4  inch  high)  are  produced  at 
scale  two,  at  which  scale  73  characters  can  be  displayed  across 
the  screen,  and  42  lines  can  be  displayed  down  the  screen. 

INDISP 

Purpose:  To  initialize  the  display  and  the  display 

file  according  the  current  state  of  the 
parameter  list  and  physically  to  start 
the  display.  * 

Calling  Sequence:  JMS  INDISP  or  INSERT  or  SUBTSK 

INDISP  INDISP 

Location  DSPBUF  is  expected  to  contain  the  first 
location  of  a  region  of  core  which  is  to  be  used  to  keep  the 
circular  file  of  characters  displayed  on  the  screen.  BUFSIZ 
contains  the  size  of  this  buffer.  The  minimum  size  region 
which  can  be  used  is  ten  (decimal)  plus  the  maximum  number 
of  characters  allowed  on  the  line.  For  example,  if  the 
maximum  number  of  characters  per  line  were  73  decimal 
(i.e.,  parameter  location  CHARLN  contained -73)  then  the 
minimum  number  that  should  appear  in  BUFSIZ  is  83.  The 


default  values  for  these  three  parameters  (i.e.,  the  values  oc¬ 
cupying  these  locations  when  the  package  is  first  loaded)  pro¬ 
vide  a  small  display  file  in  the  upper  part  of  core,  just  below 
the  system  loader. 

The  contents  of  location  PDLIST  will  be  used  to  set 
the  push-down  pointer  for  the  display.  The  default  condition 
is  to  set  it  at  4370,  by  agreement  with  L0C0SS,  so  that  four 
levels  of  push-down  are  provided  before  normal  task  space 
(at  4400)  is  invaded.  The  contents  of  location  SICLOC  will 
be  used  to  set  the  initial  conditions  in  the  display.  The 
default  value  of  4  provides  for  no  edge  flags,  a  one-by- 
one  sector,  and  no  light  pen,  edge  flag,  push-button  or 
internal  stop  interrupts.  The  low-order  ten  bits  of 
location  YLOC  contain  the  vertical  coordinate  to  be  used 
in  positioning  the  display  file.  The  default  value  of 
1760  starts  the  file  at  the  very  top  of  the  screen;  a 
value  of  1000  would  start  the  display  at  about  the 
middle  of  the  screen.  Location  LINES  contains  the  twos  com¬ 
plement  of  the  naximum  number  of  lines  to  display.  Thus  the 
file  will  contain  either  the  maximum  number  of  characters 
[C(BUFSIZ) -10]  ,  or  lines  [-C(LINES) ]  ,  whichever  is  smaller. 

The  default  value  of  40  (decimal)  lines  just  about  fills  the 
screen . 

Location  PBUSEF  controls  the  use  of  the  push  buttons. 

If  it  contains  a  nonzero  number,  the  character  generator 
package  will  neither  disturb  nor  interpret  the  push  buttons. 
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If  it  contains  zero,  the  package  will  interpret  the  push 
buttons  as  explained  in  routine  DISPLA,  and  the  initializa¬ 
tion  routine  will  clear  buttons  6-11.  The  default  value  is 
for  the  package  to  use  the  buttons. 

There  is  a  two-word  no-op  (i.e.,  zeros)  in  the  dis¬ 
play  file  created  by  INDISP.  Location  JMPUSE  contains  the 
address  of  the  first  of  these  two  locations.  If  a  user  wants 
to  add  his  display  file  to  the  display  file  maintained  by  the 
package  he  may  replace  the  two  words  addressed  by  JMPUSE  with 
a  PJMP  to  his  display  file  (being  careful  about  core  bank  bits, 
of  course).  The  file  so  added  should  then  end  with  a  POP. 

Any  change  of  this  sort  requires  that  the  display  not  be 
running  at  the  time  of  the  change.  (See  STOPDY  and  REDISP.) 

INDISP  sets  the  LOCOSS  interrupt  handling  for  ex¬ 
ternal  stop  and  manual  interrupt.  The,  external  stop  handling 
is  necessary  for  the  STOPDY  subroutine  which  is  called 
whenever  a  character  is  added  to  the  file.  Thus  the  user 
should  handle  all  external  stops  through  STOPDY.  The  default 
handling  for  manual  interrupt  is  to  reinitialize  the  display 
file,  i.e.,  call  INDISP.  If  the  user  wishes  to  use  this  button 
for  other  reasons  he  need  only  call  INTABL  after  INDISP  to 
reset  the  handling. 

After  initialization  of  the  display  file,  INDISP 
physically  starts  the  display  by  calling  RESTART. 

STOPDY 

Purpose:  To  stop  the  display  if  it  is  going. 

Calling  Sequences:  JMS  STOPDY  or  INSERT  or  SUBTSK. 


STOPDY 


STOPDY 
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STOP  DY  expects  that  the  LOCOSS  interrupt  handling 
for  external  stop  has  been  set  up  already;  thus,  INDISP  should 
be  called  before  STOPDY. 

Since  there  is  no  way  to  determine  whether  the  dis¬ 
play  is  running  or  not,  the  following  scheme  is  used  to  en¬ 
sure  that  it  is  indeed  stopped  when  control  is  returned  to 
the  user.  The  routine  issues  the  display  stop  IOT  (STPD) , 
waits  for  the  external  stop  flag  to  appear,  clears  the  flag 
if  it  does,  and  then  returns  immediately,  If,  however,  the 
display  was  not  running  at  the  time  the  stop  command  was  is¬ 
sued,  no  flag  will  appear;  STOPDY  will  wait  approximately 
i.S  milliseconds  (which  is  the  maximum  time  that  the  display 
will  delay  response  to  the  stop  command)  and  then  return 
to  the  user,  who  is  thus  assured  that  the  display  is  not 
running . 

RESTRT 

Purpose:  To  physically  restart  the  display  (on  the 

character  file  regeneration  loop). 

Calling  Sequences:  JMS  RESTRT  or  INSERT  or  SUBTSK 

RESTRT  RESTRT 

RESTRT  may  be  called  after  STOPDY  to  restart  the 
display.  It  changes  nothing  in  the  file  but  merely  issues 
the  five  IOTs  necessary  to  get  the  display  started  at  the 
beginning  of  the  file.  The  address  of  the  push-down  list 
initialization  is  taken  from  locations  PDLIST,  and  the  initial 
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conditions  are  taken  from  location  SICLOC. 

PISPLA 

Purpose:  To  add  the  one  or  two  characters  in  the  AC 

to  the  display  file. 

Calling  Sequences:  AC  =  one  or  two  characters,  then... 

JMS  DISPLA  or  INSERT  or  SUBTSK 
DISPLA  DISPLA 

The  character  generator  dispatches  on  the  low-order 
seven  bits  of  an  ASCII  character,  but  in  the  discussion  of 
control  characters  below,  the  high-order  bit  (i.e.,  bit  "200") 
is  expected  to  be  set  for  the  character  to  be  recognized  as 

given  control  character.  The  input  stream  of  characters  is 

edited  in  the  following  manner.  If  the  character  is  null 
(000),  rubout  (377),  character  mode  escape  (001  or  201),  or 
line  feed  (212),  it  is  ignored.  If  the  character  is  a  carriage 
return  (215),  a  line  feed  is  added.  If  the  character  is  a 
TAB  (211),  the  extra  spacing  required  to  postion  the  beam 
at  the  next  "tab  stop"  is  calculated  and  inserted  into  the 
file.  The  tab  stop  spacing  is  calculated  exactly  as  in  tele¬ 
printer  output  so  that  a  line  output  to  the  either  teleprinter 
or  the  display  would  have  the  same  appearance  in  spacing  on 

both  devices.  In  particular,  the  tab  spacing  is  set  from 

system  variable  TABCNT.  (Note,  however,  that  a  tab  on  the 
input  echo  line  gives  a  constant  eight  spaces  and  not  the 
proper  tab  spacing.  This  sad  state  is  caused  by  the  fact 
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that  the  echo  line  display  file  is  the  input  buffer  itself 
and  cannot  be  changed  for  mere  display  purposes.) 

If  there  is  already  the  maximum  number  of  characters 
on  a  line  (given  by  the  contents  of  the  parameter  location 
LINCNT,  as  a  negative  number  in  twos  complement  form)  and 
the  input  character  is  not  a  carriage  return  (215),  a 
hyphen  and  carriage  return-line  feed  sequence  are  added  to 
the  file  so  that  the  current  character  then  will  appear  on  a 
new  line.  When  there  are  more  than  the  maximum  number  of 
lines  in  the  file  (given  by  the  contents  of  parameter  loca¬ 
tion  LINES,  as  a  negative  number  in  twos  complement  form), 
the  top  line  of  the  file  is  deleted. 

When  a  carriage  return  is  encountered,  the  controls 
of  parameter  location  PBUSEF  are  checked.  If  PBUSEF  is  non¬ 
zero,  return  to  the  iser  is  immediate.  If  PBUSEF  is  zero, 
the  push  buttons  are  used  as  a  means  of  slowing  down  or  stop¬ 
ping  the  addition  of  lines  to  the  file,  i.e.,  the  return  to 
the  user  after  addition  of  a  carriage  return  is  slowed  down 
or  stopped.  Specifically,  return  will  not  be  made  to  the 
user  while  push-button  ten  is  on.  If  push-button  eleven  is 
on,  push-buttons  0-5  are  read  as  a  binary  number,  one  (1) 
is  added  to  them,  and  the  resulting  sum  is  used  as  the  number 
of  l/60s  of  a  second  to  delay  return  to  the  user.  Thus 
push-buttons  0-5  all  off  provide  1/60  of  a  second  delay 
between  lines,  and  push  buttons  0-5  all  on  provide  64/60  or 
1.07  seconds  delay  between  lines.  Both  methods  of  delaying 
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return  employ  a  BUSY  exit  so  that  other  task  processing  may 
take  place  in  the  meantime. 

2. 5. 2. 8  Dataphone 

The  201A  dataphone,  associated  interface,  and  software 
provide  a  half-duplex  source  and  sink  of  8-bit  characters 
from  and  to  the  regular  telephone  network.  They  provide 
a  medium-speed  (2000-bits-per-second)  link  to  any  other  data 
set  which  is  operating  under  identical  message  formats. 

In  particular,  this  includes  the  Data  Concentrator  at  the 
University  of  Michigan  Computing  Center,  which  in  turn  pro¬ 
vides  access  to  the  IBM  360/67. 

The  dataphone  package  is  available  as  a  set  of  routines 
to  be  loaded  from  the  IBM  2310  disk  (see  system  routine 
LOAD  and  the  system  file  directory)  or  'from  the  tape  labeled 
"DATAPHONE  PACKAGE."  Since  there  are  no  relocation  and 
program  linkage  facilities  in  the  current  system,  the 
package  is  loaded  into  a  predesignated  area:  14400- 
15777  octal.  This  choice  of  addresses  allows  the 
character  package  to  be  loaded  also  if  so  desired. 

All  links  to  the  dataphone  routines  are  made  through 
the  LOCOSS  transfer  vector.  Before  the  package  is  loaded, 
these  transfer  vector  locations  will  contain  the  address 
of  the  DUMMY  routine  so  that  calls  can  be  made  to  the 
dataphone  as  if  the  routines  were  actually  in  core, 
and  all  programming  considerations  (except  perhaps  timing) 
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will  be  the  same  as  when  the  dataphone  package  is 
actually  present. 

The  following  is  a  brief  description  of  the  problems 
involved  in  handling  this  device  so  that  the  user  can  appre¬ 
ciate  the  organization  involved  and  the  calling  conventions 
chosen. 

The  nature  of  the  transmission  is  serial  (bit-by-bit, 
rather  than  character-by-character),  synchronous  (both 
ends  must  agree  on  when  a  message  is  being  transmitted, 
and  transmission  takes  place  at  a  constant  rate),  and 
half-duplex  (transmission  proceeds  in  one  direction  at 
a  time).  These  three  features,  and  the  fact  that  the  line 
uses  standard  voice-grade  telephone  lines  which  are  not  of 
impeccable  quality,  have  led  to  rather  elaborate  hardware 
and  software  conventions  in  message  formatting  and  error 
checking.  Messages  are  checksummed  linearly  and  every 
data  message  is  acknowledged (i . e . ,  a  message  is  sent  to 
the  transmitting  computer)  if  its  received  and  calculated 
checksums  agree,  or  given  a  negative  acknowledgment  if 
they  do  not.  The  latter  case  implies  a  request  to  re¬ 
transmit  the  message  since  the  information  received  could 
not  be  trusted.  In  addition,  some  eight-bit  patterns  must 
be  used  as  line  control  characters  (start  of  message, 
end  of  message,  etc.),  so  that  conventions  must  be 
followed  to  allow  transmissions  of  binary  information, 
since  a  binary  combination  in  the  data  stream  may  not  be 
meant  as  a  control  character. 
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Most  of  this  mechanism  is  removed  from  the  user  and  is 
reflected  os  xy  slightly  in  the  basic  output  routines.  This 
fact  makes  the  basic  dataphone  calling  sequences  device¬ 
dependent  (i.e.,  not  exactly  like  the  other  devices),  but 
rather  simple  routines  for  the  special  case  of  alphanumeric 
data  have  been  written  to  resolve  this  conflict  For  this 
special  case  of  all-ASCII  transmissions,  message  boundaries 
are  cued  on  a  special  character  (carriage  return).  Since 
the  device  is  also  intended  to  provide  binary  transmission, 
this  resolution  is  difficult  in  general,  so  that  other 
specific  handling  is  left  to  the  user  and  the  lowest  level 
handling  will  be  of  eight-bit,  transparent  binary  characters. 

The  system  routines  handle  all  other  message  formatting, 
error  checking,  requests  for  retransmission ,  etc.  Incoming 
messages  are  not  passed  to  the  user  when  he  requests  input 
until  the  checksum  is  verified;  and  no  additional  messages 
are  sent  until  the  last  has  been  positively  acknowledged. 

The  only  exception  to  this  rule  occurs  when  an  "attention" 
is  generated  from  either  end.  An  attention  clears  any 
blocking  condition  due  to  bad  messages  or  unacknowledged 
transmissions,  and,  when  sent  to  MTS  (Michigan  Terminal 
System;  see  Bibliography)  will  cause  the  program  executing 
in  the  360  to  be  interrupted. 


Dataphone  Printouts.  Messages  which  have  bad  checksums 
are  considered  rare,  and  so  a  comment  is  printed  on  the 
teleprinter  so  that  this  special  condition  can  be  noted 
(for  possible  diagnostic  purposes)  although  the  retransmis¬ 
sion  is  handled  automatically.  If  a  message  is  received 
with  a  bad  checksum  the  comment  "%@R"  is  printed,  and 
if  a  negative  acknowledgement  is  received  in  response  to 
a  bad  transmission  from  the  PDP-7  the  comment  "%@T"  is 
printed.  If  a  spurious  positive  or  negative  acknowledgment 
is  received  (i.e.,  the  PDP-7  isn't  expecting  one),  something 
is  amiss  and  for  lack  of  anything  better  to  do,  the  comment 
"%@S"  is  printed.  An  attention  received  at  the  PDP-7  will 
clear  up  any  blocking  condition  and  cause  the  message 
" %@ A"  to  be  printed  on  the  teleprinter.  A  summary  of  all 
control  characters,  including  ACK  and  NACK,  is  given  below. 

Any  message  received  at  the  PDP-7  which  is  started  by 
an  ASCII  even-parity  STX  (202)  will  have  the  STX  stripped 
and  the  rest  of  the  message  sent  to  the  user.  A  message 
which  starts  with  an  even-parity  SOH  (201)  will  be  printed 
on  the  teleprinter  preceded  by  "V  instead  of  being 
directed  to  the  user.  A  message  to  the  PDP-7  which  needs 
an  SOM  at  the  beginning  as  part  of  the  data  and  is  not 
intended  to  be  printed  should  begin  with  an  STX  to  avoid 
the  SOH  effect.  The  STX  will  be  stripped  by  the  device 
handler  and  the  SOM  will  then  appear  first  to  the  user. 

Thus,  to  be  on  the  safe  side,  the  user  should  start  every 
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transmission  to  the  PDP-7  with  an  STX.  The  STX  will  not 
be  given  to  the  user  routine  in  the  PDP-7.  (Note  of  warning: 
other  computers  along  the  line  also  use  the  initial  STX/SOH 
convention  as  a  text /command  control  character,  stripping 
it  off  and  dispatching  the  rest  of  the  message  either  to 
the  user  or  to  its  own  command  language  interpreter, 
respectively.  Thus,  an  additional  STX  must  be  added  to  the 
message  for  every  computer  or  device  controller  in  the  line 
of  transmission  which  adheres  to  this  convention.  Most 
notably  (and  infamously),  this  includes  the  Data  Concentrator 
and  the  360  support  routines.  For  example,  to  send  an 
initial  data  SOH  from  an  MTS  program  to  the  PDP-7, the 
following  sequence  must  be  sent:  STX  STX  STX  SOU.  This 

i 

is  a  strange  convention,  and  may  be  changed  in  the  future. 
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Calling  Conventions.  In  view  of  the  foregoing,  the 
following  basic  calling  conventions  have  been  adopted. 

For  reading  from  the  dataphone,  the  user  merely  calls 
the  read  routine,  DFNRED.  All  message  checks  and  requests 
for  retransmission  are  handled  by  the  low-level  routines, 
and  the  user  is  completely  insulated  from  them.  An  in¬ 
coming  message  beginning  with  an  SOU  will  be  printed  on 
the  teleprinter  preceded  by  and  a  message  beginning 

with  STX  will  have  the  STX  stripped  and  the  rest  of  the 
message  sent  to  the  user.  The  end  of  the  message  is 
marked  by  one  of  the  end- of- record  characters:  ETX,  ETB, 

EOM,  or  EOT.  The  entire  list  is  included  here  for 
completeness'  sake  alt!  ugh,  except  for  extraordinary 
(probably  pathological)  cases,  only  ETX  and  ETB  will  be 
received  from  other  machines.  The  user  should  always 
attempt  to  read  to  the  end  of  a  message,  for  it  is  only 
then  that  the  local  system  will  transmit  a  positive 
acknowledgment  to  the  other  machine  so  that  the  latter  can 
send  another  message. 

In  transmission  of  messages  over  the  dataphone,  the  user 
must  do  three  things:  request  the  dataphone  transmission 
facilities,  send  the  message,  and  indicate  the  end  of 
message.  In  requesting  permission  to  transmit  (via  a  SUBTSK 
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of  task  DFNREQ)  the  user  implicitly  waits  until  previous 
dataphone  transmissions  have  been  completed  and  acknowledged, 
and  once  permission  is  granted  (return  from  DFNREQ), 
he  is  ensured  that  no  other  task  will  be  allowed  at  the 
dataphone  until  the  current  message  is  finished.  Once  the 
user  has  been  assigned  use  of  the  dataphone,  he  may  call 
subroutine  DFNSND  and  send  one  or  two  characters  at  a  time 
(in  a  format  similar  to  the  other  device  transfers).  The 
user  indicates  end-of-message  by  calling  DFNSND  with  bit 
zero  of  the  accumulator  set.  This  call  allows  him  to 
specify  the  default  end-of- record  character  (ETX)  or  one 
of  his  own  choosing. 

For  the  case  of  all  ASCII,  alphanumeric  transmission 
(e . g . , communicat ion  with  MTS  as  a  glorified  teletype 
terminal),  there  are  two  routines  which  have  calling 
conventions  similar  to  the  other  I/O  devices  and  which  lake 
the  mappings  from  the  record-oriented  dataphone  to  a 
stream  of  characters.  On  input,  DFNRA  maps  the  end-of- 
text  character  into  a  carriage  return.  On  output  to  DFNSA , 
a  carriage  return  ends  a  line  and  signals  that  the  next 
character  to  be  sent  starts  a  new  record.  Both  DFNRA  and 
DFNSA  call  the  respective  lower-level  routines  described 
above  so  that  the  user  should  be  consistent  in  his  choice 
of  input  or  output  routines. 


To  send  an  "attention"  over  the  dataphone  the  user 
should  call  subroutine  DFNATN.  Attentions  clear  up  any 
blocking  conditions  existing  at  eitherend. 

DFNI 

Purpose:  To  initialize  device  handling  for  the  dataphone 

to  be  the  standard  routines,  to  clear  the  data¬ 
phone  buffers,  and  initialize  the  hardware  so 
that  dataphone  operation  may  begin. 

Calling  Sequence:  10 F 

DFNI 

RETURN, - 

Subroutine  DFNI  initializes  the  hardware  by  clearing  all 
status  bits  and  then  setting  "TERMINAL  READY,"  and  setting 
the  transmission  frame  size  to  eight-bit  bytes.  DFNI 
should  be  called  (from  the  program  or  the  CLI  command 
"DAT")  immediately  after  loading  the  dataphone  package. 

DFNRED 

Purpose:  To  obtain  the  next  eight-bit  character  from 

the  dataphone  receive  buffer. 

Calling  Sequence:  DFNRED  /IOF  or  ION 

/with  character  in 
/AC, ION 


RETURN  , 
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The  end-o f- record  character  (i.e.,  the  last  character 
in  the  buffer)  is  one  of  the  following:  ETX,  ETB,  EOM, or 
EOT,  and  is  transferred  to  the  user. 

DFNREQ 

Purpose:  To  obtain  the  use  of  the  dataphone  and  to 

start  transmission. 

Calling  Sequence:  SUBT5K 

DFNREQ 
RETURN, - 

Return  is  made  when  the  dataphone  is  free  for  trans¬ 
mission,  i.e.,  when  all  previous  messages  have  been  sent 
and  positively  acknowledged.  Upon  return  the  user  is  free 
to  call  subroutines  DFNSND .  DFNREQ  must  be  called  before 
every  record  is  sent,  and  a  DFNSND  call  with  bdt  zero  of 
the  AC  set  must  be  made  to  end  every  record.  DFNREQ  starts 
the  dataphone  transmitting,  and  since  the  transmission 
is  synchronous,  nulls  (i.e.,  characters  which  the  other 
machine  will  ignore)  will  be  inserted  in  the  data  stream, 
if  data  characters  are  not  available,  to  keep  the  trans¬ 
mission  line  happy.  Thus,  until  the  record  is  ended,  the 
line  is  locked  in  transmission  mode  and  the  other  machine 
cannot  send  a  message  to  the  PDP-7.  So,  in  general, 
transmission  should  be  requested  only  if  it  can  be  foreseen 
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that  the  message  will  be  terminated  in  a  reasonable  length 
of  time  (e.g.,ten  seconds),  although  as  long  as  the  message 
is  ended  some  time  no  harm  will  be  done. 

DFNSND 

Purpose:  To  send  the  one  or  two  eight-bit  characters 

in  the  AC  to  the  dataphone,  or  to  end  the 
record . 

Calling  Sequence:  AC  =  1  or  2  characters  in  standard 

form;  or  AC  bit  zero  =  one;  and 
low-order  bits  indicate  the  end-of- 
record  character. 

DFNSND 
RETURN, - 

Any  eight-bit  pattern  may  be  sent  over  the  dataphone 
in  this  manner.  DFNREQ  must  have  been  called  as  a  subtask 
before  DFNSND  may  be  called.  For  any  transmission  longer 
than  seventy-three  (73)  characters  (including  the  end- of - 
record  character)  only  the  first  seventy-three  characters 
will  be  transmitted. 

The  record  will  be  ended  if  the  high-order  bit  of  the 
accumulator  is  set  on  entry  and  the  low-order  eight  bits 
of  the  accumulator  will  be  used  as  an  end-of- record  (EOR) 
character.  If  the  EOR  character  is  a  zero,  the  default 
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EOR  will  be  used  (ETX).  It  is  recommended  that  the  user 
choose  the  default  case  rather  than  specify  an  ETX  directly 
because  the  bit  configuration  currently  used  for  ETX  may 
be  changed  in  the  near  future.  After  DFNSND  is  called 
ending  a  message,  DFNREQ  must  be  called  again  to  start  a 
new  message.  Another  message  will  be  permitted  to  start 
when  the  current  message  is  acknowledged. 

DFNSA 

Purpose:  To  send  alphanumeric  ASCII  characters  over 

the  dataphone. 

Calling  Sequence:  AC  =  1  or  2  characters  /IOF  or  ION 

DFNSA 

RETURN, - 

A  carriage  return  (215)  will  end  a  record  and  will  be 
replaced  by  an  ETX.  The  first  character  after  the  carriage 
return  will  start  a  new  record.  End-of-page  characters 
(214)  and  local  end-of-files  (023)  will  be  sent  as  independent 
records,  ended  by  ETX. 

DFNRA 

Purpose:  To  read  eight-bit  alphanumeric  character 

information  from  the  dataphone. 

Calling  Sequence:  DFNRA 


RETURN, 


/AC  =  character 


An  ETX  will  be  mapped  into  a  carriage  return,  but  all 
other  end- of- record  characters  will  remain  the  same. 

DFNATN 

Purpose:  To  send  an  "attention"  over  the  dataphone 

and  to  clear  any  blocking  conditions. 
Calling  Sequence:  IOF 

DFNATN 


RETURN, 


/IOF 


Table  4.  Dataphone  Control  Characters 


CHARACTER 

OCTAL 

FUNCTION 

SOH 

201 

Start  of  Header 

STX 

202 

Start  of  Text 

EOT 

204 

End  of  Transmission  (Hang  Up) 

ETX 

215 

End  of  Text 

ATN(ENQ) 

005 

Attention 

ACK 

006 

Positive  Acknowledgment 

DLE 

220 

Data  Link  Escape 

NAK 

225 

Negative  Acknowledgment 

SYN 

026 

Synchronous  Idle 

ETB 

027 

End-of-Text  Block 

EOM 

231 

End  of  Message  (MTS  end-of-fi 

2.6  Buffer  Management 

For  those  who  wish  to  use  the  system  buffer  routines,  the 
following  is  a  brief  description  of  the  available  routines  and 
of  the  structure  they  assume. 

Buffers  in  LOCOSS  are  linear  and  fixed  in  size.  The  in¬ 
formation  contained  in  the  buffers  may  be  in  either  alphanumeric 
mode  or  binary  mode.  In  binary  mode,  all  eighteen  bits  of  the 
word  are  considered  as  a  whole  and  are  moved  about  as  such.  In 
alphanumeric  mode,  the  lower-order  sixteen  bits  of  a  word  are 
broken  into  two  eight-bit  halves.  The  right-half  byte  is  always 
considered  significant.  The  left-half  byte  is  significant  only 
if  it  is  nonzero.  When  a  word  is  put  into  a  buffer  in  alpha¬ 
numeric  mode  the  word  is  not  split  up  but  goes  in  as  a  whole. 

As  an  option  on  alphanumeric  PUTS,  the  two  bytes  will  be  packed 
in  the  buffer  if  both  the  last  word  put  into  the  buffer  and  the 
current  word  being  put  both  consist  of  only  one  byte  and  the 
last  word  PUT  was  nonzero  and  has  not  yet  been  read. 

On  retrieval,  the  left-hand  byte  is  considered  first  and, 
if  significant,  is  returned  to  the  user.  Then  the  right-hand 
byte  is  given  to  the  user.  By  the  calling  sequence,  the  user 
indicates  which  mode  is  to  be  set  in  PUTing  things  into  a  buf¬ 
fer.  The  GfcT  routine  returns  the  next  thing  from  the  buffer  and 
indicates  whether  it  was  PUT  in  alphanumeric  or  binary  mode. 

Each  buffer's  status  is  indicated  by  a  five-word  Buffer 
Control  Block  (BCB) .  The  form  of  the  BCB  is  as  follows: 
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Word  1:  Location  of  the  buffer 

Word  2:  Flags  and  Size 

Bit  0  =  1  Buffer  may  be  packed  on  alphanumeric 
PUTS. 

Bit  3  =  1^  Locked  to  output.  Information  may 
not  be  taken  from  this  buffer. 

Bit  4  =  1  Locked  to  input.  Information  may  not 
be  put  into  this  buffer. 

Bit  5  =  1  >  Buffer  in  binary  mode. 

Bit  6  =  1  =►■  Buffer  in  alphanumeric  mode. 

Bit  5  *  Bit  6  =  0  >  Buffer  empty. 

Bit  6  -  17  =  Size  of  buffer  (max  =  3777  octal). 

Word  3:  PI— Inbound  Pointer.  The  last  word  put  into  the 

buffer  (if  any)  went  into  this  location.  Thus 
the  next  word  goes  into  location  PI  ♦  1. 

Word  4:  PO-Output  Pointer.  The  next  word  to  be  taken  from 
the  buffer  (if  non-empty)  is  at  adt-ress  PO  +  1. 

Word  5:  Temporary  Storage— for  the  right-hand  character  in 
an  alphanumeric  fetch. 

For  example,  the  initial  BCB  for  the  teleprinter  routines 
looks  like: 

TPRBCB,  TPRBUF  /location  of  a  buffer 

400017  /of  size  15,  originally  empty,  lock 

/bits  off, packing  allowed 
TPRBUF  /PI 

TPRBUF  /PO 

0  /temporary  storage 

The  following  routines  clear  a  buffer,  get  from  and  put 

into  it,  and  lock  and  unlock  it  to  input  and  output.  The  user 
need  only  reserve  the  buffer  area  and  set  up  the  original  BCB. 
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The  routines  then  do  all  the  work.  Note  that  all  buffer  control 
routines  must  be  called  with  interrupts  off,  and  that  return 
is  made  with  interrupts  off. 

CLEARB 

Purpose:  To  reset  a  buffer  control  block  to  indicate  that 

the  buffer  is  empty. 

Calling  Sequence:  IOF 

CLEARB 

BCB 

RETURN,  - 

BCB  is  the  address  of  the  associated  buffer  control  block. 

PUT 

Purpose:  To  put  a  word  into  a  buffer. 

Calling  Sequence:  LINK=M0DE 

AC=W0RD 

IOF 

PUT 

BCB 

ERRET,  AC=W0RD 
RETURN,  - 

Where:  Mode  =  1  for  binary  put 

=  0  for  alpha  put 

BCB  is  the  address  of  the  associated  buffer  control  block. 

If  the  buffer  is  full,  locked  in,  or  already  contains  information 
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in  a  different  mode  than  in  the  calling  sequence,  control  is  re¬ 
turned  to  location  ERRET  with  the  AC=W0RD  and  the  word  not 
having  been  put  into  the  buffer.  If  the  word  has  been  put  into 
the  buffer,  control  is  transferred  to  location  RETURN.  Note 
that  the  error  condition  has  a  two-word  return,  i.e.,  RETURN= 
ERRET+  2  . 

GET 

Purpose:  To  retrieve  the  next  item  from  a  given  buffer. 

Calling  Sequence:  IOF 

GET 

BCB 

ERRET,  - 

RETURN,  -  /AC  *  ITEM,  LINK=MODE 

Where:  BCB  is  the  associated  buffer  control  block 

ERRET  is  the  location  transferred  to  if  the 
buffer  is  empty  or  locked  out. 

RETURN  is  the  location  transferred  to  on  suc¬ 
cessful  retrieval. 

MODE  =  1  ►  the  item  returned  is  binary  (18  bits) 

=  0  >  the  item  returned  is  alphanumeric 
(8  bits) 

ITEM  is  the  available  information  from  the 
buffer . 

NOTE:  The  low-order  16  bits  of  an  alphanumeric  word  taken  from 

the  buffer  are  split  into  two  eight-bit  halves  or  bytes 
and  given  one  at  a  time,  left  byte  first,  to  the  user. 
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However,  if  the  left  byte  is  all  zeros  it  is  ignored 
and  the  right  is  given  immediately.  The  right  byte  is 
always  returned  whether  it  is  zero  or  not.  This  con¬ 
vention  is  to  allow  characters  to  be  put  into  the  buf¬ 
fer  either  one  or  two  at  a  time. 


LOCKBI 

ALOWBI 

LOCKBO 

ALOWBO 

Purpose:  To  allow  and  disallow  transfers  to  and  from 

buffers . 

Calling  Sequence:  IOF 

LAW  BCB  +  1  /address  of  BCB  status 

word 


XXXXXX 

Where:  XXXXXX  is  one  of  the  routines: 

LOCKBI  -  Lock  buffer  to  input,  i.e.,  disallow 
PUTs. 

ALOWBI  -  Allow  buffer  input. 

LOCKBO  -  Lock  buffer  to  output,  i.e.,  disallow 
GETs  . 

ALOWBO  -  Allow  buffer  output. 
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SUBTSK“JMS 

1 

24 

/INSERT  A  PROGRAM  AS  A  SUBTASK 

1 NSERT“ JMS 

1 

25 

/INSERT  AN  INDEPENDENT  TASK 

BUSY  “JMS 

1 

26 

/COME  BACK  LATER 

DELETE“JMP 

1 

27 

/DELETE  THE  CURRENT  TASK 

CREATE*JMS 

1 

30 

/CREATE  A  UNIQUE  EVENT  NUMBER 

WAIT  “JMS 

1 

31 

/WAIT  FOR  AN  EVENT  TO  OCCUR 

S 1 GNAL= JMS 

1 

32 

/SIGNAL  THE  OCCURRENCE  OF  AN  EVENT 

1 NTABL“ JMS 

1 

33 

/ENTER  INTERRUPT  HANDLER  INTO  INTERRUPT  TABLE 

RDRA  “JMS 

1 

34 

/GET  ALPHANUMERIC  CHARACTER  FROM  READER 

RDRB  “JMS 

1 

35 

/GET  BINARY  WORD  FROM  READER 

RDRI  “JMS 

1 

36 

/INITIALIZE  TAPE  READER 

PCHA  “JMS 

1 

37 

/PUNCH  ALPHANUMERIC  CHARACTER 

PCHB  =JMS 

1 

40 

/PUNCH  BINARY  WORD 

PCHI  “JMS 

1 

41 

/INITIALIZE  TAPE  PUNCH 

TPRA  “JMS 

1 

42 

/TYPE  ALPHANUMERIC  CHARACTERS 

TPRI  “JMS 

1 

43 

/INITIALIZE  TELEPRINTER  ROUTINES 

KBDA  “JMS 

1 

44 

/READ  ALPHANUMERIC  CHARACTER  FROM  KEYBOARD 

KBDI  “JMS 

1 

45 

/INITIALIZE  KEYBOARD  ROUTINES 

CLEARQ“  JMS 

1 

47 

/CLEAR  THE  TASK  QUEUE 

CLEARE= JMS 

1 

50 

/REINITIALIZE  EVENT  HANDLING 

CLEARB-JMS 

1 

51 

/CLEAR  A  BUFFER  CONTROL  BLOCK 

RESET  “JMS 

1 

52 

/REINITIALIZE  ALL  OF  LOCOSS 

GET  “JMS 

1 

53 

/GET  A  CHARACTER  FROM  A  BUFFER 

PUT  “JMS 

1 

54 

/PUT  A  CHARACTER  INTO  A  BUFFER 

RDRSEL“JMS 

1 

55 

/START  THE  TAPE  READER 

PRMPTC* 

56 

/PROMPTING  CONTROL;  0  “>  GIVE  PROMPT 

ECHOSW“ 

57 

/ECHO  CONTROL;  0  “>  ECHO  KEYBOARD 

TABCNT= 

60 

/TAB  STOP  SETTING 

KBDLOC“ 

61 

/LOCATION  OF  KEYBOARD  BUFFER  CONTROL  BLOCK 

DFNRED“ JMS 

1 

62 

/GET  CHARACTER  FROM  DATAPHONE 

DFNSHD“JMS 

1 

63 

/SEND  A  CHARACTER  TO  THE  DATAPHONE 

DFNREQ“ 

64 

/SEIZE  DATAPHONE  FOR  TRANSMISSION 

DISK  “JMS 

1 

66 

/TALK  TO  IBM  1800  INTERRUPT  ROUTINE 

DSKERR“ JMS 

1 

67 

/SET  ERROR  RETURN  FROM  "DISK"  CALL 

DSKGET= JMS 

1 

70 

/GET  A  CHARACTER  FROM  A  DISK  FILE 

DSKPUT“ JMS 

1 

71 

/PUT  A  CHARACTER  INTO  A  DISK  FILE 

LOCKBO“ JMS 

1 

72 

/LOCK  BUFFER  TO  OUTPUT 

ALOWBO“ JMS 

1 

73 

/ALLOW  BUFFER  OUTPUT 

LOCKB 1 “JMS 

1 

74 

/LOCK  BUFFER  TO  INPUT 

ALOWBI “JMS 

1 

75 

/ALLOW  BUFFER  INPUT 

CLOCK  “JMS 

1 

76 

/SET  RETURN  FROM  INTERVAL  TIMER 

LOAD  “JMS 

1 

77 

/LOAD  A  FILE  FROM  THE  DISK 
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DFNI 

-JMS 

i 

100 

/INITIALIZE  DATAPHONE 

CLOCKI 

-JMS 

i 

101 

/INITIALIZE  CLOCK  ROUTINES 

RDRLOC 

U 

102 

/LOCATION  OF  READER  BUFFER  CONTROL 

BLOCK 

PCHLOC 

m 

103 

/LOCATION  OF  PUNCH  BUFFER  CONTROL 

BLOCK 

DFNSA 

-JMS 

i 

104 

/SEND  ALPHANUMERIC  CHARACTER  TO  DATAPHONE 

DFNRA 

-JMS 

i 

105 

/READ  ALPHANUMERIC  CHARACTER  FROM 

dataphdne 

DUMMY 

-JMS 

i 

106 

/DUMMY  ROUTINE.  BOTH  SOURCE  AND  SINK,  TOO. 

RDOCT 

-JMS 

i 

107 

/READ  OCTAL  NUMBER 

RDDEC 

-JMS 

i 

110 

/READ  DECIMAL  NUMBER 

PROCT 

-JMS 

i 

111 

/OUTPUT  OCTAL  NUMBER 

PRDEC 

-JMS 

i 

112 

/OUTPUT  DECIMAL  NUMBER 

DFNATN 

■ 

113 .  . 

/SEND  ATTENTION  OVER  DATAPHONE 

SYSDSK 

-JMS 

i 

114 

/TALK  TO  IBM  1800,  WITH  IMMEDIATE 

ERROR  RETURN 

ASCOUT 

■JMS 

i 

115 

/OUTPUT  A  LIST 

ICYRDT 

-JMS 

i 

116 

/READ  FROM  IBM  1800  COPY  PORT  TRANSLATED 

ICYWRT 

-JMS 

i 

117 

/WRITE  TO  IBM  1800  COPY  PORT  TRANSLATED 

ICYINI 

-JMS 

i 

120 

/INITIALIZE  IBM  COPY  PORT  ROUTINES 

TRMCHR 

U 

121 

/TERMINATING  CHARACTER  FOR  RDOCT  AND  RDDEC 

SOURC1 

m 

122 

/ASSIGNABLE  SOURCES 

SOURC2 

s 

123 

SOURC3 

■ 

124 

SINK1 

■ 

125 

/ASSIGNABLE  SINKS 

SINK2 

m 

126 

SINK3 

m 

127 

LEDING 

u 

130 

/LEADING  ZERO  REPLACEMENT 

SEZTPR 

m 

131 

/SEIZE  TELEPRINTER  ROUTINES 

ICYRDU-JMS  I  133 
I  CYWRU- JMS  I  134 


/READ  FROM  IBM  1800  COPY  PORT  UNTRANSLATED 
/WRITE  TO  IBM  1800  COPY  PORT  UNTRANSLATED 


/DISK  OPERATOR  DEFINITIONS 


D . ECH0-00400 

/01 

ECHO 

D.O POT* 01000 

/  0  2 

OPEN  OUTPUT  FILE  TRANSLATED 

D.OPI T-01400 

/  03 

OPEN  INPUT  FILE  TRANSLATED 

0.  PUT  -02000 

/  04 

PUT  TO  OUTPUT.  FILE 

.GET  -02400 

/  0  5 

GET  FROM  INPUT  FILE 

U.CLO  -03000 

/06 

CLOSE  OUTPUT  FILE 

D.CLI  -03400 

/  0  7 

CLOSE  INPUT  FILE 

D.CLk  -04000 

/  08 

CLOSE  ALL  FILES  AND  CLEAR 

D.CRE  -04400 

/  09 

CREATE  FILE 

D.DES  -05400 

/II 

DESTROY  FILE 

D.0POU-06400 

/ 1 3 

OPEN  OUTPUT  FILE  UNTRANSLATED 

D.OPI U-07000 

/ 14 

OPEN  INPUT.  FLLE  UNTRANSLATED 

D.ECOA-IOOOO 

/ 16 

EBCDIC  TO  ASCI  1  ECHO 

D. ECOB-10400 

/ 1 7 

ASCI  1  TO  EBCDIC  ECHO 

D. BOOT-llOOO 

/ 1 8 

BOOTSTRAP  STYLE  LOAD 

D. REDT-11400 

/ 19 

READ  FROM  COPY  PORT  TRANSLATED 

D. WRIT-12000 

/  20 

WRITE  TO  COPY  PORT  TRANSLATED 

D.REDU-12400 

/  21 

READ  FROM  COPY  PORT  UNTRANSLATED 

D.WRI U-13000 

/  2  2 

WRITE  TO  COPY  PORT  UNTRANSLATED 

FIX 

PAUSE 


1 
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AL0WB1 

120075 

ALOWBO 

120073 

ASCOUT 

1201 1 5 

BUSY 

120026 

CLEARS 

120051 

CLEARE 

120050 

CLEARQ 

120047 

CLOCK 

120076 

CLOCK 1 

120101 

CREATE 

120030 

DELETE 

620027 

DFNATN 

1  13 

DFNI 

120100 

OFNRA 

120105 

DFNRED 

120062 

DFNREO 

64 

DFNSA 

120104 

DFNSND 

120063 

DISK 

120066 

DSKERR 

120067 

DSKGET 

120070 

DSKPUT 

120071 

DUMMY 

120106 

D*  BOOT 

11000 

D.CLI 

3400 

D.CLO 

3000 

D.CLR 

4000 

D.CRE 

4400 

D.DES 

5400 

D.ECHO 

400 

D.ECOA 

10000 

D.ECOB 

10400 

D.  GET 

2  400 

D.OPIT 

1  400 

D.OPIU 

7000 

D.OPOT 

1000 

D.OPOU 

6400 

D.PUT 

2000 

D.REDT 

11400 

D.  REDU 

12400 

D.  WRIT 

12000 

D.  WRIU 

13000 

ECHOS W 

57 

GET 

120053 

ICYINI 

120120 

ICYRDT 

120116 

ICYRDU 

120133 

I CY  WRT 

120117 

ICYWRU 

120134 

INSERT 

120025 

INTABL 

120033 

KB  DA 

120044 

KBDI 

1200  45 

KBOLOC 

61 

LEDING 

130 

LOAD 

120077 

LOCKBI 

120074 

LOCKBO 

120072 

PCHA 

120037 

PCHB 

120040 

PCHI 

120041 

PCHLOC 

103 

PRDEC 

120112 

PRMPTC 

56 

PROCT 

120111 

PUT 

120054 

RDDEC 

1201 10 

RDOCT 

120107 

RDRA 

120034 

RORB 

120035 

RDRI 

120036 

RDRLOC 

102 

RDRSEL 

120055 

RESET 

120052 

SEZTPR 

131 

SI  GNAL 

1 20032 

SINK  1 

125 

SINK2 

126 

SINKS 

127 

SOURCl 

122 

S0URC2 

123 

S0URC3 

124 

SUBTSK 

120024 

SYSDSK 

120114 

TABCNT 

WAIT 

60 

120031 

TPRA 

120042 

TPRI 

120043 

TRMCHR 

121 
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APPENDIX  B 

SYSTEMS  INFORMATION 

The  information  in  this  section  is  meant  to  provide  as¬ 
sistance  in  understanding  the  program  listings  and  thus  to  aid 
program  maintenance.  In  general,  LOCOSS  is  a  collection  of 
subroutines  and,  as  such,  the  description  of  the  individual 
subroutines  and  the  general  comments  at  the  head  of  each  sec¬ 
tion  provide  most  of  the  information  needed  to  specify  completely 
the  action  taken  by  an  individual  routine.  In  these  cases  the 
comments  in  the  listings  and  the  description  in  the  user's 
manual  will  not  be  supplemented  here.  There  are,  however,  four 
sections  of  interest  in  which  there  is  an  underlying  structure 
not  completely  specified  in  the  user's  manual  and  which  must  be 
understood  in  order  to  make  sense  from  the  listings.  These  are: 
the  structure  of  the  task  queue,  the  structure  of  the  event 
table,  the  mechanism  of  the  Command  Language  Interpreter,  and 
the  conventions  for  information  transfer  across  the  IBM  1800- 
PDP-7  interface.  An  additional  topic,  the  structure  of  the 
loaders,  is  discussed  in  the  section  on  core  image  formats. 

TASK  QUEUE 

The  task  queue  is  a  fixed-length  buffer  containing  a 
linked  list  of  task  control  blocks  (TCBs) .  A  TCB  contains 
the  information  needed  to  start  some  program  as  a  task.  It 
consists  of  five  words  with  the  following  format. 
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Word 

Word 


Word 


Word 

Word 


Calls 


:  Link  pointer  to  the  next  task  in  the  queue. 

:  Lvent  control  word. 

Bit  0:  =0  This  TCB  is  not  part  of  an  event  chain, 

i.e.,  it  was  put  into  the  queue  by 
INSERT,  SUBTSK,  or  BUSY,  and  may  be 
started  in  the  normal  manner. 

=1  This  TCB  is  part  of  an  event  chain. 

Do  not  activate  it  until  bit  zero  is 
zero  . 

:  Activation  word. 

Bit  0:  =0  Enter  as  a  JMS  when  the  task  is 

enterab le . 

=1  Enter  as  a  JMP  when  its  turn  comes 
(always  enterable)  . 

Bits  5-17:  Location  of  program  entry  point. 

:  Return  pointer,  Bits  0-17,  meaningful  only  for 

JMS  entry , 

:  Parameter  word,  Bits  0-17.  This  was  the  contents 

of  the  accumulator  when  the  multiprogramming 
system  was  called  and  will  be  restored  before 
control  is  returned  to  the  user  program. 

to  INSERT  and  SUBTSK  cause  the  activation  word  to 


be  set  wholly  from  the  location  following  the  calling  instruc¬ 
tion  so  that  thi  user  has  control  over  the  method  of  entry  to 
the  addressed  task  (by  setting  the  high-order  bit  as  desired). 
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BUSY  sets  the  high-order  bit  of  the  activation  word  so  that 
return  will  be  made  via  a  JMP  entry.  These  three  calls  all 
zero  the  event  control  word.  A  call  on  WAIT  sets  the  activa¬ 
tion  word  as  in  BUSY,  sets  bit  zero  of  the  event  control  word 
to  one} ana  sets  the  rest  of  the  word  as  described  below  in  the 
event  descriptions. 

The  multiprogramming  system  maintains  three  variables 
which  describe  the  state  of  the  queue.  QHEAD  contains  the 
address  of  the  first  TCB  in  the  linked  list,  i.e.,  the  next 
TCB  to  be  activated.  QTAIL  contains  the  address  of  the  last 
TCB  on  the  list,  i.e.,  the  point  at  which  another  TCB  may  be 
added  to  the  list.  QFREE  contains  the  address  of  the  first 
unused  TCB  in  a  linked  list  of  free  storage. 

Upon  initialization,  all  of  the  area  used  for  the  queue 
is  split  into  five-word  blocks,  and  linked  together,  forming 
the  free  storage  list.  The  first  word  of  each  block  is  a 
pointer  to  the  next  block,  and  the  end  of  the  list  is  marked 
by  a  zero  pointer.  One  five-word  block  is  reserved  as  the 
"idle  task."  This  TCB  has  its  event  control  word  set  so  that 
it  is  never  activated.  Its  link  pointer  points  to  itself  so 
that  the  list  forms  a  ring.  Both  QHEAD  and  QTAIL  point  to 
the  idle  task  TCB. 

The  task  control  loop  operates  as  follows.  The  TCB  ad¬ 
dressed  by  QHEAD  is  considered  for  activation.  If  the  TCB 
may  not  be  activated  it  is  put  at  the  end  of  the  queue;  that 
is,  the  pointers  QHEAD  and  QTAIL  are  changed  so  that  QTAIL 
points  to  the  rejected  task  and  QHEAD  points  to  the  next  task 
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in  the  queue  (the  TCB  addressed  by  the  link  pointer  of  the  re¬ 
jected  TCB) .  If  the  TCB  may  be  activated  (i.e.,  the  event 
control  word  is  not  set  and  the  task  is  enterable),  it  is  re¬ 
moved  from  the  queue,  and  control  is  transferred  to  the  task 
in  the  appropriate  manner. 

Removal  from  the  queue  consists  of  closing  up  the  link 
pointers  and  adding  the  used  TCB  to  the  free  storage  list. 

Used  TCBs  are  linked  to  the  head  of  the  free  storage  list  and 
new  TCBs  are  obtained  also  from  the  head  of  the  fre^  storage 
list.  A  new  TCB  is  created  by  calls  to  INSERT,  SUBTSK,  BUSY, 
and  WAIT,  and  is  added  to  the  queue  by  obtaining  a  TCB  from 
the  free  storage  list  and  linking  it  into  the  queue  after  the 
TCB  addressed  by  QTAIL.  The  link  pointer  of  the  new  TCB  is  set 
to  point  to  the  TCB  addressed  by  QHEAD.  Thus  the  queue  is  al¬ 
ways  maintained  as  a  ring  of  TCBs.  At  initialization  time  the 
ring  consists  of  one  TCB  which  can  never  be  removed  from  the 
list,  and  which  points  to  itself.  Insertions  and  deletions 
from  the  queue,  then,  only  expand  and  contract  the  size  of  the 
ring  . 

If  at  any  point  a  new  TCB  is  needed  and  the  free  storage 
head,  QFREE,  points  to  a  zero  word,  there  is  no  room  in  the  inn 
and  control  is  passed  to  the  LOCOSS  error  handler. 

EVENT  CONTROL 

The  event  table  consists  of  a  fixed  number  of  Event  Con¬ 
trol  Blocks  (ECBs),  consisting  of  two  words  each.  If  the  first 
word  of  the  ECB  is  zero  the  block  is  not  being  used.  If  the 
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first  word  is  nonzero  then  its  contents  (a  number)  name  an 
event  which  has  been  created  and  which  has  not  yet  been  sig¬ 
naled.  The  second  word  of  t.he  block,  then,  is  a  pointer  to 
the  head  of  a  linked  list  of  Task  Control  Blocks  (TCBs)  naming 
tasks  which  have  called  subroutine  WAIT  with  the  event  named 
as  parameter;  i.e.,  these  are  tasks  awaiting  the  occurrence 
of  the  named  event.  If  the  second  word  of  the  ECB  is  zero, 
then  no  tasks  have  yet  executed  calls  on  WAIT. 

When  a  user  program  calls  CREATE,  a  unique  number  for  an 
event  is  produced  by  using  the  contents  of  location  EVNO.  After 
this  number  is  used,  the  contents  of  EVNO  are  incremented  by 
one  so  that  the  next  call  on  CREATE  will  produce  a  different 
number.  A  search  is  then  made  of  the  event  table,  looking  for 
an  ECB  with  a  first  word  zero  (i.e.,  an  unused  ECB).  If  none 
is  found,  control  is  passed  to  the  error  processor.  If  an 
empty  ECB  is  found,  the  new  event  number  is  stored  in  its  first 
word  establishing  it  as  an  occupied  ECB;  the  second  word  is 
zeroed,  indicating  that  no  tasks  are  waiting  for  the  event. 

When  a  task  calls  WAIT,  a  search  is  made  of  the  event 
table  for  the  event  given  in  the  call.  If  an  ECB  for  the 
named  event  does  not  exist,  it  is  assumed  that  the  event  has 
already  occurred  or  that  it  has  not  been  created  yet,  and 
control  is  returned  immediately  to  the  user.  If  the  event 
has  an  ECB,  a  TCB  is  created  for  the  task  and  added  to  the 
task  queue.  The  event  control  word  of  the  TCB  (word  two)  is 
then  established  as  the  head  of  the  linked  list  of  TCBs  waiting 
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for  that  event  to  take  place.  The  end  of  the  list  is  indica¬ 
ted  by  Bits  1-17  of  the  event  link-pointer  (TCB  word  two)  being 
zero.  Word  two  of  the  ECB  is  then  set  to  point  to  the  head  of 
the  list  of  TCBs.  Note  that  the  list  is  a  sequence  of  TCB- 
word-twos,  not  of  the  TCBs  themselves. 

When  a  program  calls  SIGNAL,  a  search  is  made  of  the 
event  table.  If  the  event  named  has  no  ECB,  return  is 
immediate  to  the  calling  program,  since  the  event  has  already 
taken  place,  or  was  never  really  created.  If  the  event  does 
have  an  ECB,  the  list  of  TCBs  is  threaded,  zeroing  all  the 
event  control  words,  thus  enabling  those  TCBs  to  be  reacti¬ 
vated  the  next  time  they  come  up  for  reconsideration.  The 
first  word  of  the  ECB  is  then  zeroed,  indicating  that  the 
event  has  occurred.  Any  further  WAITs  or  SIGNALS  will  have 
immediate  returns  since  no  ECB  exists  for  that  event. 

THE  COMMAND  LANGUAGE  INTERPRETER 

The  CLI  is  a  straightforward  command  processor  which  cues 
on  three-letter  commands  and  dispatches  to  the  specific  handler 
for  each  command.  For  those  commands  taking  numeric  parameters, 
the  CLI  uses  "RDOCT"  and  "RDDEC"  routines  very  similar  to  the 
ones  available  to  users  and  described  in  the  section  on 
general  routines.  For  the  device  assignment  commands,  the 
syntax  is  enforced  by  restricting  the  portion  of  the  command 
table  which  will  be  searched. 

The  CLI  is  an  inte rrupt - t ime  package.  This  means  that 
any  command  entered  via  the  keyboard  is  acted  upon  as  soon  as 
the  keyboard  routines  receive  the  interrupt  from  the  entry  of 
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the  carriage  return  ending  the  line.  This  feature  ensures  that 
the  CLI  is  always  available  to  the  user  and  that  the  user  may 
be  sure  that  his  request  is  acted  upon  as  soon  as  it  is  recog¬ 
nized;  that  is,  the  CLI  does  not  have  to  compete  with  task  time 
for  CPU  control  or  for  system  resources  (subroutines,  teleprinter, 
etc.).  However,  there  are  some  command  functions  which  require 
that  interrupts  be  turned  on.  For  example,  a  DMP  command  may 
require  the  output  of  several  lines  of  numbers.  Interrupts 
may  not  be  turned  off  during  the  time-consuming  output  of  these 
numbers  since  there  is  at  least  one  synchronous  device  (the 
dataphone)  which  must  run  under  interrupt  control.  To  achieve 
this  capability  the  CLI  essentially  "pushes  down"  task-time  con¬ 
trol  and  establishes  itself  as  the  active  task.  More  specifi¬ 
cally  the  CLI  saves  all  the  interrupt-saved  registers  and  then 
turns  interrupts  on.  If  an  interrupt  occurs  during  CLI  pro¬ 
cessing,  the  interrupt  identifier  saves  the  registers  as  usual 
and  then  processes  the  interrupt  normally.  Upon  completion  of 
the  servicing,  the  interrupt  processor  restores  the  registers 
for  the  CLI  and  returns  control  to  the  CLI.  When  the  CLI  is 
done  processing,  it  restores  the  registers  it  has  pushed  down 
and  transfers  control  to  the  interrupted  task-time  program. 

The  only  possible  source  of  embarrassment  which  may  occur 
is  re-entry  to  the  CLI  while  it  is  already  executing.  This 
nuisance  is  remedied  by  cutting  it  off  at  the  source — the 
keyboard  dispatcher.  If  a  keyboard  interrupt  occurs  while  the 
CLI  is  executing,  the  registers  which  were  pushed  down  are 
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immediately  popped  up  so  that  the  interrupt  processor  will  use 
these  first-level  registers  upon  return  from  the  keyboard  pro¬ 
cessing,  and  thus  return  control  to  the  task-time  routine 
originally  interrupted.  Thus,  a  keyboard  interrupt  will  abort 
CLI  activity;  and,  since  it  is  only  by  keyboard  activity  that 
the  CLI  may  be  invoked,  the  CLI  will  never  be  invoked  while 
already  running. 

IBM  1800  COMMUNICATION  ROUTINES 

All  communication  with  the  IBM  1800  across  the  "minor" 
interface  is  performed  on  a  request  basis  (with  one  exception*) 
with  the  PDP-7  initiating  all  information  transfers.  The  data 
path  from  the  PDP-7  to  the  1800  is  sixteen  bits  wide.  Of  this, 
the  high-order  eight  bits  are  used  to  specify  a  function  to  be 
performed  by  the  1800  service  routine.  The  low-order  eight 
bits  are  treated  as  data  according  to  the  specific  function  re¬ 
quested.  In  general,  the  data  may  be  an  eight-bit  character, 
a  file  number,  or  immaterial. 

Upon  receipt  of  the  information  from  the  7,  the  1800  at¬ 
tempts  the  function  requested  and,  in  the  twelve-bit  path  from 
the  1800  to  the  7,  returns  either  a  four-bit  positive  or  nega¬ 
tive  acknowledgment  to  the  request  and  an  eight-bit  data  byte. 
Again,  depending  on  the  function,  the  datum  may  be  a  character, 

*  Brender,  R.F.,  Frantz,  D.R.,  Foy,  J.L.  Jr.,  and  Schunior, 

T . W . ,  Special i zed  System  Software  for  Interacting  DEC 
PDP-7  and  I BM  1800,  Technical  Report  11,  Concomp  Project, 
University  of  Michigan,  Ann  Arbor,  October  1968. 

L 


an  error  code  (in  case  of  negative  acknowledgment),  or  it  may 
be  meaningless  . 

To  check  for  possible  failure  of  the  interface  in  actual¬ 
ly  transferring  information,  the  disk  routines  perform  time¬ 
outs  on  the  two  directions  of  information  transfer.  Thus,  if 
the  1800  is  not  listening  (i.e.,  does  not  have  a  pending  read), 
the  disk  routines  will  wait  about  a  second  and  a  half,  and  then 
return  an  error  code  to  the  user's  program. 
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